osm2city.py development

[vanosten]

Pylons and cables between pylons now basically works for both power lines and aerialways. What is still missing are decent shared models for aerialways, making the cables bend and eventually adding overhead cable markers plus improving the algorithm.

The following two screenshots are using both osm2city and osm2pylons near LSZS.

Power line: the pylons are placed based on OSM data. The cables (yellow and too thick to make the point) are dynamically generated based on the chosen pylon type etc. Normally there would be isolators, too.


Aerialways: the pylons are chosen and placed based on OSM data (right now they are barely visible because I use streetlamps until I have made some shared models). The cables are in blue and too thick to make a point.

[Hooray]

that's looking pretty good, you may want to update the wiki and/or the newsletter accordingly (feel free to upload those screen shots there)

[Johan G]

Pylons and cables between pylons now basically works for both power lines and aerialways. What is still missing are decent shared models for aerialways, making the cables bend and eventually adding overhead cable markers plus improving the algorithm.

Very nice. This is a feature that have been requested before, see the topic How to make lines between power pylons?

Note: Cable markers are only used in some situations, like when the distance between the pylons is longer or the power line is higher up. Two common examples is when power lines cross rivers or valleys. Se below quote for the ICAO recommendations:

The ICAO recommendations on them is available here as an pdf. See page 3 in the pdf, section 2.6.8.

Thanks to owenpsmith cable markers are available as shared objects in Shared - Power Generation & Distribution in the scenery database (though for some reason I can not find them at git in fgdata/Models/Power).

[f-ojac]

There is no more sync between scenemodels data and the git fgdata.

[vanosten]

Unfortunately I do not understand what your comment means - neither in general nor with the above subjects.

[f-ojac]

Vanosten,
This was in answer to:

(though for some reason I can not find them at git in fgdata/Models/Power).

Sry it's a bit hard to quote with my mobile terminal on long messages.

[vanosten]

A little update. Cables can now sag - based on a parameter for a catenary function and a parameter for the number of sub-segments per cable. In the pictures below a= 1500 and 4 sub-segments already gives IMHO an ok impression.

Next steps are to make sure that the sagging looks also ok if there is a considerable difference of elevation between 2 pylons. And then document/publish.

[Soitanen]

Great!!! Simply awesome!

[ludomotico]

If I understand correctly, this could be easily extended to include rail power-lines, traffic lights on motorways, automatic airport boundaries or any other "line of objects"

[radi]

Nice work!

sagging looks also ok if there is a considerable difference of elevation between 2 pylons

Might be overkill, since I reckon a simple parabola will look convincingly enough. But if you want to get an exact result for the parameter a, follow wikipedia, section "Determining parameters", and solve the one transcendential equation using scipy's root finding capabilities. scipy.optimize.brentq usually works nicely for me. I can give an example, if need be.

[Johan G]

Those looks great. They will be a nice addition to the low flying environment.

Maybe it is time I get current. It is over a month since I last flew, and that was not low either. I would hate to get "trapped".

[F-JYL]

Nice job ! Thanks.

[Thorsten]

Looks very good!

Might be overkill, since I reckon a simple parabola will look convincingly enough.

For large differences in elevation? I don't think so...

This is all done offline, right? So it's not like we need to safe on performance as we'd have to inside a shader effect.

[vanosten]

Yes, this is all offline as a sub-system to osm2city (Python). Actually I see this as a proof of concept - and later (might not happen this year) some of it could be used as pre-processed datapoints for further processing dynamically in C++ "online".

And yes, it could be extended for e.g. railway overhead lines. However I guess that for railways textured line data is more important than overhead lines. Also: osm2pylons uses (at least currently) OpenStreetMap point data for the positioning of pylons - for railways the positioning would have to be done based on line-data etc.

Actually I believe that if we use more polygons for the catenary sagging, then it is also worth approximating tension (see e.g. https://en.wikipedia.org/wiki/File:Catenary-tension.png) - however I will only approximate it - maybe because my math is a bit rusty

I would be glad if someone with more actual flight experience could enlighten me about the markers on overhead wires. The ICAO recommendations cited in this thread are a bit fluffy - and naturally it depends on actual local situations, which of course are difficult to interpret based on map data ...

AFAIK there is no tagging in OSM for markers - therefore everything would need to be calculated based on map-data and elevation data

I would be glad for pointers to pictures of situations with markers

The definition of a valley is not that trivial. So I would go for that there must be either a river or street of some category (can be parametrized) in the valley before it really counts (in mountainous areas otherwise there would be too many situations where there is a "valley" between pylons)

I guess that the overhead wires must be quite some meters above the valley before it counts. More than e.g. 100 meters / 300 feet?

Is there a "rule" for when also obstacle lights are used?

"crossing a river, valley or highway": While river and highway could be parametrized based on OSM-tags, I am still afraid that there must be additional "local" criteria before markers are used. At least in my area there are no markers on overhead wires (high voltage) despite them crossing a highway.

The thing with markers being: I am afraid that there would be too many markers in general - and then missing markers in specific situations. So the question is whether it is worth the hassel and/or if it should be attempted to introduce tags in OSM for the same before any further work is done.

[Soitanen]

Vanosten - will this script work with transition between power=tower and power=pylon tagged points?
Situation like in this panorama. On the right you can see power pylon, but wires go to power pole (need to scroll picture to the left).