Newly Duplicated Stations

I am noticing quite a few 2024 duplications of existing stations in the U.S. This seems especially prevalent when the original station was added by a user and the newly added station was added from the US’s AFDC database. One such example is as follows:

  • Added by a ‘user’ in 2023: OCM-289095
  • Added by a ‘AFDC’ this year: OCM-293609
    It looks like the newly-added station is over 100 meters from the original station and I am wondering if that is somehow factoring in.

Yes, if a site is at a different location it is not considered a duplicate by our automated import. We don’t really have a perfect solution for that.


I have seen lots of those AFDC duplicates in Canada (AFDC also collects Canadian data, they get it from Natural Resources Canada). In the latest example that I have come across AFDC marker for Electrify Canada station with six 350 kW chargers was placed in the middle of a large shopping mall, most likely because this is the official postal address. The chargers are actually located in the parking lot about 100 metres away.

A workaround I use for now is to change the operational and usage status of those bad AFDC markers to “Planned For Future Date / Restricted Access". Deleting them did not work, they would just reappear after the next AFDC import.

This will hopefully get resolved in the future, check post #3 in my thread here:

The most straightforward resolution is just for us to not run the AFDC import, most imports eventually outlive their usefulness and it sounds like this one has as well.

I don’t know how bad those AFDC imports are overall in the US but in Canada they are definitely not that great. I have been doing some cleanup in the last few minutes and it didn’t take long to find another great AFDC exhibit:

OCM 295696

“Pet Vulu - Tesla Supercharger” (should be “PetValu”)
“Public - Credit card at all times” (there are no Superchargers with credit card readers in Canada)
“6x 50 kW DC” (should be 250 kW)
“kW power is an estimate based on the connection type” (so all NACS connections run at 50 kW?)
“Usage:Public - Pay At Location” (cash, credit, how about bitcoin?)
“Tesla (including non-tesla)” (at least they got this right, it is NACS Supercharger)

In regions where there are active editors those AFDC imports are a real nuisance. And for regions without active editors the question is what is better: bad data or no data?

In the U.S. I have developed code to detect duplicates and have been hand editing to eliminate them. It might be possible to use this same logic to prevent the duplicates from being generated in the first place. I have noticed that duplication usually occurs in the following situation.

  • The import duplicates a station that had first been entered by a user
  • The locations of the two stations are located further apart than about >= 100 meters.
    To reduce the probability of a future import creating another duplication I have been eliminating the older (user generated) duplicated station. I wonder if this logic (or similar) could be applied to the import such that the duplication would not occur in the first place.
    Here’s a report for a newly-generated duplication in Alabama, USA. I’ve been using this report to eliminate duplication and also to identify things like invalid chargers-per-station counts and power mostly in the US. But it also works in Canada for the reasons stated by Christopher.
    I am in favor of continuing to import AFDC in the USA because it gets most of the initial data data correct (lat/lng, address, # of chargers, etc.) even though it does generate some duplication.
1 Like

Automate de-duping sounds good in principle.

Is there any information on the manually entered locations that you are deleting that should be conflated with the AFDC imports? I am thinking of photos of the stations in particular but there could be other information.

That’s a great question because determining the true location is critically important for EV drivers and particularly difficult to ascertain with the available information. The location (lat/lng) from the sources seems to sometimes come from the mailing address which can be (for example) in the middle of a mall. I suspect users may be getting the lat/lng from their phones GPS and they are often not parked at or near the charging station when the generate a new station in the app. In any case, I am finding lat/lng discrepancies of hundreds of meters, sometimes more.

To determine the true lat/lng I often go into google maps’ streetview. If the station is visible then it is easy to determine the true lat/long, but unfortunately it is often not visible. Sometimes there are pictures in PlugShare that can be studied. Stations are sometimes shown as POI’s in google maps but these are occasionally wrong. If a user has posted a picture taken from a cell phone then the lat/lng of the location where the picture was taken, not the charging station, may be available in the picture. I have made no effort to pursue yet this because US OCM picture availability is rare.

Stations occasionally have issue with invalid address. An invalid address can be particularly pernicious for an EV driver. Imagine navigating to a station with a depleted battery but the station is not there. I also check and occasionally find and fix invalid addresses. Most bad addresses in the U.S. are with Tesla, probably because Tesla’s navigation system keys off the lat/lng (which are nearly perfect) rather than the address so the addresses don’t get checked-then-fixed. But with the rollout of other EV’s that are able to charge at Tesla stations it would be good if the OCM addresses could reliably be used for navigation. Personally, it will be GREAT when we can charge at Tesla stations in our Bolt … hopefully soon. Note that PlugShare also occasionally uses a better address than that given by the station provider.

I am thinking of posting a web tool to identify just those OCM stations with these types of issues.

For what it is worth, when I have added or edited stations in OCM I use the background map (which is OpenStreetMap based) and set the location to match what I saw on the ground. So I am not using GPS data directly but assuming the OSM background map is correct the lat/lon should be pretty close.

A hiking organization I am associated with has a bad setup where if you specify meeting location via lat/lon will do a reverse geo lookup to get a street address. Then use the street address to set the lat/lon. For a large wilderness park with multiple trailheads and one address roughly in the center this is horrible. We usually tell people to follow the written directions rather than go off the website’s location.

That experience leads me to suspect addresses for things other than houses or specific stores. The middle of a parking lot does not get mail delivery so many geo coding systems do a poor job of locating things there.

For that reason, and because I often don’t have a good way of finding the official street address, I usually don’t edit the address of a charger in OCM. If I do add/edit the address it will be from the network’s app but geocoders may well place that address more than 100 yards/meters from the chargers if located in a large shopping center.

Yes the interesting thing about Addresses is that chargers don’t have one, even though we traditionally give them one. The address is intended to the the closest navigable location and the lat/long is intended to be the exact spot where you would find one or more of the chargers. Realistically though networks feed all sorts of information (good and bad) and initially we just trust it for the most part.