How to remove certain OSM Buildings ?

[StuartC]

How can I remove an OSM placed building to stop it appearing on or in a custom scenery building ?

[Thorsten]

You can't remove individual buildings - they are not separate, they come in chunks. The idea is to regularly re-run OSM2City because at building generation time intersection with existing objects can be tested and taken into account.

But since such checks are expensive, they're not done runtime, all of the magic happens when the OSM layer is created.

[N-SCOT]

Hi,

I don't know for sure if this is an answer for this Q, but I found a 2011 thread with a link to https://scenery.flightgear.org/submission/ which allows for removal of shared objects in scenery.

G

Edit: from thread

Subj: Scenery webtools (adding, editing, deleting objects&models).
Postby: f-ojac » Thu Dec 15, 2011 4:16 am

[f-ojac]

Yes, but not for OSM stuff or random objects, just for statis or shared objects/models.

[N-SCOT]

Ahh, pity that.

So I get that the OSM is not updated / edited frequently because of reasons. However, I'm sure that this must happen with some degree of frequency. Is there (or should there be) a list of coordinates, such as airports with buildings in the middle of runways, or spikes / pinnacles from the landmass rendering, etc. so that on the next OSM generation these can be fixed? Or is what have a WYSIWYG for all time? In short, is there a corrective process (albeit infrequently applied) or is there just no process?

G

[vanosten]

As Thorsten has described above, OSM buildings are generated in large meshes (default 2km*2km) as one single ac-file/object. And this process is at generation time, which currently is whenever someone like me generates a scenery. There are plans to both cover larger parts of the world with OSM generated scenery as well as doing this automatically and regularly (e.g. if a certain amount of scenery objects [especially static ones] have changed - and/or OSM data has changed). However the amounts of data are significant.

I do not know of a central place, where issues like the ones described by N-SCOT are described. Basically there are at least the following possibilities of "errors":

• The static or shared scenery object has been placed at a wrong location (in which case it needs to be corrected in the scenery database)
• An OSM registration is off (in which case you can correct it in OSM - if "off" means wrong in the real world, because e.g. a runway in FG scenery could be placed in the wrong spot)
• A programming error (which might unfortunately be the most common case) -> let me know (e.g. until recently if a street crossed a runway (which is valid OSM data), then the street continued across the runway - but because the road texture is laid e.g. 10 cm above the ground, you would sense a bump on the runway apart from a visual problem).

[wkitty42]

10cm or 10mm? i would think that maybe 2mm separation should be ok... am i missing something?

[vanosten]

10cm or 10mm? i would think that maybe 2mm separation should be ok... am i missing something?

You are "missing" a few facts: First of all the distance is configurable in osm2city at generation time. Secondly: due to multiple ways being able to cross each other osm2city separates them by a little distance vertically, i.e. not every way has the same distance.

The configuration parameter is due to the fact that the scenery is not necessarily flat. And depending on the distance of points along the way the mesh might actually interfere with the ground mesh and get hidden etc. So depending on the bumpiness of the ground you have to find a compromise between the number of faces in the mesh when choosing smaller values of POINTS_ON_LINE_DISTANCE_MAX (i.e. you get more points, which can be set better according to the underlying ground level above sea at the cost of more triangles) and having larger values of MIN_ABOVE_GROUND_LEVEL (leading sometimes to visible floating roads if your eye point is very close to the ground [which is seldom in flight sim]) and the possibility of parts of a way to be hidden.

[Thorsten]

10cm or 10mm? i would think that maybe 2mm separation should be ok... am i missing something?

Yes - accuracy of the z-buffer from the distance for starters.

[wkitty42]

ahhh... ok... for some reason i just thought there would be more "terrain sampling" so things like roads followed the flow of the land more closely... but then i think about how "loose" the data is that we have to work with... it just seems like we could tighten up a bit more... hehehe, i remember the c172p breaking its landing gear just by crossing over the lines painted on the taxiways due to this elevation situation...

[LesterBoffo]

With my experience with OSM generated .ac road models, at the actual surface level if you drive one of the many cars or bikes for FG on an OSM road, you encounter all sorts of coplanar elevation deviations and dips above below the terrain mesh. not to mention some serious 'steps' at certain intersections on the road surface itself, often times the FG scenery supplied road surface is better to drive on.

Yeah I know, it's a flight sim, not a driving or swimming sim.

[Thorsten]

for some reason i just thought there would be more "terrain sampling" so things like roads followed the flow of the land more closely...

Even if you have two perfectly co-planar triangles, from 10 km away you need some separation for the z-buffer to separate them correctly.

In fact, for the taxiway lines (which do not have a crash-detection relevant displacement by the way, only the on-screen pixels are displaced) we cheat and vary the offset from the runway with the viewing distance to get this right.

[vanosten]

Turns out I forgot something important: in osm2city at scenery generation time you can actually exclude buildings and roads using parameter SKIP_LIST, which is a list of strings. In the current code it looks for a "name" key in OSM and compares the value for buildings - respectively the id for roads/, railways. That is actually maybe what StuartC and N-SCOT are looking for.

An example is LSPM in Switzerland, where you currently cannot land due to buildings on the runway, where the root cause is that the runway is ca. 100 meters in the wrong spot. Such situations can temporarily by solved by adding to the SKIP_LIST before generating osm2city scenery.

Now the current code is not ideal by looking at the "name" key for buildings. I created https://gitlab.com/fg-radi/osm2city/issues/63

[vanosten]

SKIP_LIST now also works with osm_id for buildings as described in the docs.