Open stefanpernpaintner opened 1 year ago
For the initial merging of charging properties and address data, the 3 tables helped a bit, i.e. now it's chosen which table/object (address, charging) from which source to prefer. But in the end we should compare attribute by attribute when merging, which is a bit more effort.
We should consider https://github.com/comsysto/eCharm/issues/30 though, our data model currently does not support charge points, while original datasets are structured this way (even the row based BNA and FRGOV data)
Schema redesign: Idea was to have one flat table with rows containing all attributes of a charging station (including address + basic charging attributes). Current design with 3 tables doesn't make sense (1:1 relationships) and complicates the whole process