How to Send Us Your GIS + Mapping Data
Last updated: September 3, 2026
What to export, in what format, so your grid shows up on the map correctly the first time.
Your GIS data is what lets Texture put your grid on the map — meters, transformers, lines, poles, switches, and how they all connect to each other. This guide covers what to send us, in what format, and the handful of details that save the most back-and-forth during onboarding.
What to send
Send your mapping/GIS export. This is the export from your GIS or mapping system (for example, ArcGIS, NISC iVue IIRC, or similar). It carries the geometry — points and lines — plus the asset details for each device, typically organized as one file per asset type: meters/consumers, transformers, overcurrent devices (reclosers, fuses), lines/spans, poles and other support structures, generators, substations, capacitors, regulators, and switches.
Send your grid hierarchy export, if you have one. This typically comes from your engineering or mapping-and-staking system (for example, Milsoft/Windmill or an equivalent). It shows how elements connect — which meter feeds from which transformer, feeder, and substation — and often carries the engineering detail (impedance, conductor specs, ratings) that powers features like real-time power flow modeling.
Use one of our accepted formats. We can work with a GeoJSON FeatureCollection (preferred), Esri JSON (FeatureSet), a shapefile, a file geodatabase, or a plain CSV of latitude/longitude with a label. If you're not sure which you have, send what you've got and we'll take it from there.
Check your fields against the table below. A handful of fields are required for us to ingest anything at all; the rest are optional and unlock more as you provide them — see "Required vs. optional fields."
IMPORTANT Don't convert your coordinates — tell us the projection instead. Send coordinates exactly as your system holds them, along with the projection or EPSG code. Converting coordinate systems yourself before sending is one of the most common sources of small mapping offsets — we'll handle the conversion on our end once we know what format you're starting from. |
Required vs. optional fields
Required fields are what we need just to ingest an asset at all. Everything else is optional — some fields are worth prioritizing because they unlock specific features, noted below.
Field | Required? | Applies to | Why it matters |
|---|---|---|---|
Unique ID (element ID / GUID / asset ID) | Required | All assets | Ties the same asset together across your GIS export, hierarchy export, and SCADA. An asset without one can't be ingested. |
Coordinates | Required | All assets | Places the asset on the map. Send them exactly as your system holds them. |
Coordinate system / EPSG code | Optional — recommended | Whole delivery | Tells us how to convert your coordinates to our map projection correctly. |
Asset type (transformer, meter, pole, span, etc.) | Required | All assets | Determines how the asset is modeled and displayed. |
Parent / upstream element ID | Optional — required for hierarchy | Assets in your hierarchy file | Builds the tree (meter → transformer → feeder → substation) that powers rollups. |
Meter number | Optional — Required if you've provided meter data | Service points, generators | Links a mapped meter to billing/customer records. |
Phase | Optional — recommended | Most device types | Improves connectivity and engineering accuracy. |
Equipment ratings (kVA, amperage) | Optional — required for power flow modeling | Transformers, overcurrent devices, regulators | Powers real-time voltage and load calculations. |
Conductor / impedance specs | Optional — required for power flow modeling | Spans (lines) | Needed to calculate voltage drop along a line. |
Transformer bank ID | Optional | Transformers | Groups multi-unit banks so they're modeled as one logical unit. |
SCADA point mapping | Optional | Metered/monitored assets | Links a mapped asset to real-time telemetry, if you have SCADA. |
Data dictionary / field definitions | Optional — strongly recommended | Whole delivery | Prevents us from misreading coded fields (what does a "3" mean in this column?). |
Other metadata (install/inspection dates, responsible crew, etc.) | Optional | Any asset | Anything you'd want to search, filter, or display on the map is worth including. |
Sample files
Two small example files are included alongside this guide:
sample_gis_export.geojson — a GeoJSON export covering four asset types (transformer, service point, span, pole), with the accompanying README.txt mapping each field to required or optional.
sample_minimum_viable.csv — the bare-minimum format: just latitude, longitude, and a label.
Good to know
A minimum viable dataset is just latitude/longitude and a label. If a full export isn't ready, a CSV with coordinates and a name is enough to get your assets on the map. It won't power hierarchy or grid analytics, but it's a fine starting point.
Send both files for a complete picture. An asset that only appears in your GIS export will show up on the map without connectivity; an asset that only appears in your hierarchy export won't be mapped at all. Sending both for the same assets is what gives you the full picture — location and hierarchy.
Files can be split by asset type. Separate files per device type — transformers, spans, service points, poles, and so on — are expected. You don't need to merge them into one file.
Coordinate precision matters for CSV data. If you're sending raw latitude/longitude, use at least 5 decimal places. 4 decimal places (roughly 14 meters of error) is enough to merge neighboring poles on the map. For point and line geometry, make sure every coordinate is a valid, finite value and every line has at least two vertices — incomplete geometry gets dropped rather than guessed at.
Let us know your update cadence. A one-time historical export plus a regular refresh (weekly, monthly, or ad hoc) works well — just tell us what to expect so we can plan around it.