Hi all,
First let me disclose that I’m a new contributor to OSM and still a bit of a novice. So please be patient as I navigate the norms of OSM.
I’d like to get the City of Toronto’s public EV charging stations (the Green P / Toronto Parking Authority network) properly mapped in OSM. Thankfully there is open data for this to get started.
The plan is a MapRoulette challenge where each task is one charging site, pre-populated with suggested tags, that a mapper reviews, positions, and either accepts or fixes by hand.
For starters each task is just to add the station as a POI node. Ambitious contributors could make it an area with the stalls and chargers mapped out, per the OSM Wiki entry on Tag:amenity=charging_station. In my view, that’d be a subsequent pass.
Thanks to @skfd for helping me get started. It quickly became clear my naive assumption of using the City of Toronto’s raw Open Data GeoJSON is insufficient. I had to incorporate the US’s AFDC open data to uniquely identify each physical station location. Unfortunately the two datasets do disagree, so a script had to be written to assist on a “final” GeoJSON suitable for use in MapRoulette.
Script and output: https://github.com/f3ndot/osm-toronto-ev-charging-station-importer
(AI Disclosure: I used Claude Code to generate the script. And also help collect my thoughts in writing this post)
Sources
- Alternative Fuels Data Center (US DOE): surprisingly, the best structured source for Canadian charging infrastructure. Filtered to Electric / Canada / Ontario, it has 188 records whose station names identify them as Green P. Updated frequently with every record in my download had
date_last_confirmedset to the download date. It also carries connector types, per-connector kW, addresses, postcodes and network IDs. - City Operated Electric Vehicle Charging Station Map (City of Toronto Open Data): 82 site-level features with the City’s own level-2 / level-3 port counts and an On-Street vs Green P lot distinction.
Neither is sufficient alone, which is the whole reason for the merge. The AFDC has the technical detail but no operator attribution; the City confirms operatorship and port counts but has no connector or power data, and is noticeably stale — it’s missing at least 27 sites the AFDC knows about.
In a perfect world, I could just use City of Toronto’s dataset. But without unique IDs in its features, I can’t make use of ref=* or ref:*=* tags that would make this sustainable on dataset refreshes/updates.
I find it funny that in the current political climate the US’ source is more powerful and what’s necessary to get this job done in a Canadian city than that city’s own data. Not my preference but oh well.
What the script does
Groups AFDC records into physical sites. AFDC granularity varies by network: ChargePoint-network Green P stations get one record per EVSE post (GREENP CP52-001 … -006 are six records for the single 40 York St garage), while FLO ones get one per charger group (GreenP - CP36 - 110 Queen St W. - 1 / -2 / -3 / -4 / - Fast Chargers). Records are grouped by the Green P site code (CP82, LocationID 5562) plus normalised address.
Matches the two sources by address first, then proximity, because neither coordinate set can be trusted on its own — AFDC’s GREENP CP96 and the City’s site both read “10 Portland St” yet sit 577 m apart, while the City’s “500 Commissioners St” matches an identically addressed AFDC record 193 m away.
Flags rather than hides disagreement. Every conflict between the sources lands in the feature’s fixme and a QA report, including three cases where the City lists one address twice and two where an AFDC coordinate is clearly wrong.
Example output for Green P CP82, 9 Emerson Ave (two AFDC records merged — a 6-port level 2 group and a 2-port fast charger):
amenity=charging_station
access=yes
fee=yes
motorcar=yes
capacity=8
socket:type1=6
socket:type1:output=16.6 kW
socket:type1_combo=2
socket:type1_combo:output=50 kW
name=FLO
brand=FLO
brand:wikidata=Q64971203
network=FLO
network:website=https://www.flo.com
network:phone=+1-888-356-8911
operator=Toronto Parking Authority
operator:type=public
operator:wikidata=Q7826466
addr:housenumber=9
addr:street=Emerson Avenue
addr:city=Toronto
addr:postcode=M6H 3S7
opening_hours=24/7
start_date=2025-11-20
check_date=2026-09-01
ref:afdc=446035;446036
fixme=please set exact location; please convert into area with individual stalls and charging points
Tag mapping follows the US AFDC Manual Sync Project, with two Canadian departures: no addr:state, and J1772 maps to socket:type1 rather than the European socket:type2.
Current numbers as of Sept 1st, 2026
Data inputs, output, and report here: osm-toronto-ev-charging-station-importer/datasets/2026-09-01 at main · f3ndot/osm-toronto-ev-charging-station-importer · GitHub
| AFDC Green P records in scope | 188 |
| Physical sites after grouping | 105 |
| City of Toronto site records | 82 |
| Proposed MapRoulette tasks | 106 |
| Confirmed by both sources | 78 sites |
| AFDC only (absent from City extract) | 27 sites |
| City only (absent from AFDC) | 1 site |
| Total charge points | 563 |
| Sites with a DC fast charger | 23 |
| Tasks carrying an extra data-quality warning | 17 |
Open questions
What started as “just use the City’s dataset” has turned into a merge script with judgement calls. Naturally it’s led me to have open questions that you fine folks can hopefully answer or discuss. I’m not married to anything, so chime in with what you think is best.
-
Nothing is conflated against existing OSM data yet. This is the biggest gap and I’d like advice on the right approach: match on
ref:afdcfirst, then look for untaggedamenity=charging_stationnodes within some radius? Should tasks for stations that already exist in OSM be dropped, or included as “check and update” tasks? -
One node per site, or one per AFDC record? I’ve gone with per-site, so 36 of the 106 tasks merge 2–11 AFDC records and
ref:afdcbecomes a semicolon list (worst case: 11 values at 20 Charles St E). That matches what a mapper actually sees in a garage, but semicolon-delimited refs are ugly and it diverges from the one-node-per-AFDC-id convention the US project uses. Preferences? -
name=FLOis probably wrong? It’s the network brand, not a name, and I only did it because it’s what the AFDC sync project produces and I noticed existing charging stations in OSM for Toronto are also using brand names (for example). Should these be unnamed,name=Green P, or something else? Relatedly: isnetwork=*appropriate on a charging station, or should this bebrand+operatoronly? This seems to be an open debate within OSM. -
The two sources disagree on port counts at 10 sites, sometimes badly — at 75 Holly St the City says 28 level-2 ports and the AFDC says 10. I currently let the City win, since it’s the operator of record, and write both numbers into a
fixmeso the mapper surveys it. Is deferring to the City right, or should the more recently refreshed AFDC number win? -
Should
fixmebe in the imported data at all? Every task currently carriesfixme=please set exact location; please convert into area with individual stalls and charging points. That’s honest about the data quality, but it also means importing 106 fixmes into the map. Would it be better to leave that entirely in the challenge instructions and import clean tags? -
Node now, or area with individual charging points? The ideal end state for a garage with 12 posts is presumably the parking area plus individual
amenity=charging_stationnodes per post — which is exactly the detail the AFDC’s per-post records could support. But that’s a much bigger ask per task. Is a single node per site an acceptable first pass? -
Coverage and operator edge cases. 27 sites exist in the AFDC but not the City extract, so I’m trusting the AFDC’s “GreenP” naming rather than the City’s list to decide scope — reasonable? Also, a handful of city-operated sites clearly aren’t Toronto Parking Authority (Toronto Zoo lots, community centres), and I currently tag them
operator=Toronto Parking Authorityregardless, which needs a manual pass. -
Licensing. The AFDC data is US federal government work; the City data is under the Open Government Licence – Toronto. I want to confirm both are OK for OSM, and settle the attribution. I’m confident they’re both compatible, but curious if there’s anything specific I need to put in tags or the output to be the most correct. FYI the AFDC terms associated with their GeoJSON download has this preamble (emphasis mine):
These data and software code (“Data”) are provided by the National Laboratory of the Rockies (“NLR”), which is operated by the Alliance for Energy Innovation, LLC (“Alliance”), for the U.S. Department of Energy (“DOE”), and may be used for any purpose whatsoever.
-
Import vs MapRoulette. Contradicting everything I’ve written so far, would this be better served as a straight import by myself instead of an MR challenge? Since I’ve gone so far as to write a utility script, arguably it could become stable enough with all your feedback to just import into OSM directly without the “human-in-the-loop” hurdle of MR. But I want to be conservative and MR feels way less scary to me than an import by my hand as a new contributor.
What I’d like
Feedback on 1–9, especially anything that would make the resulting edits harder for other mappers to live with. If the structure looks broadly sound, I’ll document it on the wiki, follow whatever parts of the Import Guidelines apply to a manually reviewed challenge, and post the challenge here for review before opening it to other mappers.
Thanks for reading.