Closed lukasol closed 7 years ago
Just checked the cases mentioned above. There are 17 lines out of 19689 with implausible cable information. Some (at least one**) of them are clearly part of the railway grid and must have somehow slipped through. Others though are clearly part of the public grid (checked e.g. for operator), but for some reasons mapped with cables = 2 or cables = 4. There may be mapping errors, but at least a few*** are obviously mapped like that on purpose...
Since I don't want to restructure core functions of osmTGmod because of this, I propose two options:
Any opinions? @ulfmueller @maltesc @mariusves
** There is one clear railway case (www.openstreetmap.org/relation/226206) where osmTGmod must have overruled the frequency tag from 16.7 to 50. The branch is part of the final set with cables=2 and freq=50. *** This case: www.openstreetmap.org/way/43605882 is interesting because cables = 4 and it is even explained in the description.
The note in this line could also be an explanation: http://www.openstreetmap.org/way/83202111
@ulfmueller @mariusves Is this still an issue? I have never received feedback so I am uncertain if I should implement any of the above stated changes?!
I just checked again. There are 13 branches with cables=4 and 1 branch with cables=7. Looking at the above stated examples I'm really not so sure on how to handle these exceptions. I would tend to your option 2, with a little variation of changing lines with cables=4 to cables=3, as this seems rather to be the case. What do you think?
Ok, thanks for your feedback. I did a very dirty adjustment and set cables = 4 and cables = 7 to be cables = 6.
There are a few branches with cables=4 and cables=7 which is hard to understand in a three-phase power system. Check via
SELECT branch_id, f_bus,t_bus,cables,branch_voltage/1000 as un_kv, link_type FROM calc_ego_osmtgmod.branch_data WHERE cables not in (3,6,9,12,15,18);
Possible reason: missing consideration of frequency in
otg_unknown_value_heuristic ()