As I can only subscribe to, but not post to the devel-list (something about my reply-to-address etc. which I do not have the time to fix now), I will repost my answer here:
Please allow me to give my personal view on the discussion regarding the integration of osm2city (same disclaimer as Keith).
* I agree that it is a good idea to have new STG verbs. I would like to ask to consider whether they could get more generic names. I guess we just need to distinguish between [A] STATIC as in unique objects manually added, [B] SHARED individual objects based on objects in the scenery database, [C] clusters of facades for volume objects like buildings and [D] clusters of facades for linear objects like roads. It is naming w.r.t. what we handle, and not so much an association to where it comes from (e.g. osm2city could also have competition from procedural city ...).
* If it makes sense to do clustering by LOD, then let us do it and have it as part of the verb. 2 or 3 levels? I do not know - osm2city (building part) uses 3 levels.
* osm2city related scripts do a lot more than buildings. Maybe this thread is only about buildings, So just for the records: volume like objects for (train) platforms, volume like objects for piers, line like objects for roads and railways, line and volume objects for power lines, aerialways etc. Actually osm2pylon is "competing" with pylons (without the wires) already in the scenery.
* Currently the number of available textures for buildings is limited. And support to apply textures by region is in its beginnings - but not difficult to extend (actually on my todo list). Meaning: it all looks very Western European.
* IMHO facade clusters generated out of OSM information alone works fine in cities (ergo osm2"city"). For residential areas or villages it does not give very good results - here actual "shared objects" should be included into clusters (maybe / maybe not shared objects from scenery database - I am experimenting).
* It is not ideal that the textures need to be copied around in each scenery object sub-folder. There should be a possibility to store them more centrally - a place in FGDATA or somewhere else, which is reserved for outside generated textures etc. Actually it will be a bit more complex, because once we would have lots of regional textures, then we do not want to fill memory with textures for the whole global area (unless we assume that whoever actually wants to use osm2city also has a graphics card, where lets say 50-100 MB of textures does not matter).
* osm2city related scripts do not make a diff between what has been in an OSM-extract used last time and the currect OSM-extract. For several reasons: ease of extract logic, difficulties to decide when a change in geometry or even tags are enough to require an update - and most importantly because you would have to go back and find out, in which existing cluster to place an object (ok, we could preserve the OSM ID in the AC-objects). In each case providing a facility like terrasync to just push out deltas for som2city stuff would be non-trivial.
* osm2city related scripts are slow - profiling might reveal some easy to fix stuff - and hard-core Python coders might also find easy optimizations. What has not been implemented for good reasons is concurrency: [A] atomicy is not so easy due to relations and [B] it is much easier to parallelize just by tiles. osm2city has a batch mode with possibility to parallelize - however I do not find it safe. So just trigger batch mode for whole 1x1 degree areas in parallel can gain speed.
* There are some glitches in OSM data vs. the rest of the scenery: e.g. buildings in the water because the cost line of OSM and e.g. Corine data differ. The fix is easy by reading FG scenery data into the same process as generating OSM-data. However that makes the process even more complicated than it currently is.
* Before osm2city related scripts could be merged into FG, at least some clean-up of dead code and directory structure should be done. Also I do not want to loose commit rights.
* For the records: I am infrequently working on OpenStree Map Would-Be Buildings (
https://gitlab.com/vanosten/owbb). This might once in the future address the most probably biggest problem right now: too few objects/buildings have been mapped in OSM - and coverage varies a lot even within smaller areas. So OSM can actually look worse than without.
Therefore from my point of view:
* I very welcome new STG verbs. I will help the other osm2city developers to implement the changes.
* Maturity of osm2city related scripts to include into the FG toolchain plus low predictability of outcome given lack of mapped buildings around the globe -> might be a bit early.
* If I can be of any help in explaining how the scripts work or if the documentation (
http://osm2city.readthedocs.io/en/latest/index.html) is ambiguous: I am happy to help.