Allow semi-colon list in frequency=*

[midgard]

Currently frequency=* is validated against this regex in resources/data/validator/numeric.mapcss:

^(0|[1-9][0-9]*(\.[0-9]+)?)( (kHz|MHz|GHz|THz))?$

Semi-colon separated lists should also be recognized as valid, for power lines with multiple circuits at different frequencies. This is common when power lines for the railways are piggy-backing on transmission power lines, e.g. at ​https://www.openstreetmap.org/way/208904880.

Expected: assertNoMatch: "way frequency=50;50;16.7";

Actual: "way frequency=50;50;16.7" matches and gives validator warning

[skyper]

How common are multiple values for frequency=*? Can we come up with a list of tags where multiple values are allowed? I guess it should be allowed for some power tags but not all. How about railway=*?

[midgard]

How common are multiple values for frequency=*?

Currently 287 ways, mostly in Switzerland and Germany, according to ​https://overpass-turbo.eu/s/1uqA

Can we come up with a list of tags where multiple values are allowed? I guess it should be allowed for some power tags but not all.

Off the top of my head, for the power tags they are (at least) voltage=*, wires=*, operator=*, operator:wikidata=*, ref=*, ref:circuits=*.

cables=* and circuits=* do not take multiple values.

How about railway=*?

Do you mean to ask which railway tags take multiple values? Since parallel tracks are mapped individually, this is not common. It does happen when parallel tracks are mapped as a single OSM way, e.g. for new tracks where no imagery is available yet.

In that case (when tracks>1), off the top of my head: voltage=*, electrified=*, frequency=*, voltage=*, ref=*, railway:track_ref=*.

[francois.lacombe]

Hello

Same answer as #22633 https://josm.openstreetmap.de/ticket/22633#comment:2

frequency values should go in a relation involving power lines.
Allowing and validating a list in frequency=* (plus operator, operator:wikidata and ref) is a workaround and not very suitable to describe power grid topology.

In France (where there are no 16.7 Hz network for railway), frequency goes in the circuit relation as soon as it is created.
Physical lines can bear any frequency, it's not a property of physical components.

See this discussion: ​https://wiki.openstreetmap.org/wiki/Proposal_talk:Power_routing_proposal#Splitting_logical_from_physical_infrastructure

I'm more in favor of voting power routing proposal instead of spending time to adapt frequency=* for several frequencies.

[skyper]

Replying to midgard:

How common are multiple values for frequency=*?

Currently 287 ways, mostly in Switzerland and Germany, according to ​https://overpass-turbo.eu/s/1uqA

Thanks.

Can we come up with a list of tags where multiple values are allowed? I guess it should be allowed for some power tags but not all.

Off the top of my head, for the power tags they are (at least) voltage=*, wires=*, operator=*, operator:wikidata=*, ref=*, ref:circuits=*.

cables=* and circuits=* do not take multiple values.

Oh, sorry, I meant to ask which power=* are allowed to have multiple values for frequency=*. voltage=* is interesting, too, regarding this ticket but the rest is not checked by validator. My thought behind the question is the option to only support multiple values with certain tags.

How about railway=*?

Do you mean to ask which railway tags take multiple values? Since parallel tracks are mapped individually, this is not common. It does happen when parallel tracks are mapped as a single OSM way, e.g. for new tracks where no imagery is available yet.

In that case (when tracks>1), off the top of my head: voltage=*, electrified=*, frequency=*, voltage=*, ref=*, railway:track_ref=*.

I am thinking about electrified single tracks with a AC overhead contact line and another DC contact line at the bottom next to the track.

[francois.lacombe]

I'd add that using frequency on power lines' ways is the same as intending to put public transport frequencies on the highways' ways they go over.

Despite it would be done on good will, it's not really efficient nor maintainable.