Board index FlightGear Development Scenery

osm2city.py development

Questions and discussion about enhancing and populating the FlightGear world.

Re: osm2city.py development

Postby vanosten » Thu Nov 24, 2016 4:40 pm

wlbragg: could you please make the .ini file available and tell me the coordinates of those "small housing track"? Then I can have a try. For the houses my immediate guess is that you have a relatively high numbers for BUILDING_MIN_AREA and BUILDING_REDUCE_RATE. I normally run with 40 respectively 0.01.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 411
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby wlbragg » Thu Nov 24, 2016 7:05 pm

Area of interest is http://www.openstreetmap.org/way/93019351#map=16/37.8077/-96.7956
The .ini is bare bones and for the most part is using the defaults in parameters for all areas I am building. This is the area with the housing that is sparse.
Code: Select all
PREFIX = "w097n37"
PATH_TO_SCENERY = "/home/wayne/FGFS/Scenery/kansas/output"
PATH_TO_OUTPUT = "/home/wayne/FGFS/osm2city/Kansas/custom/state/w097n37"
PATH_TO_OSM2CITY_DATA = "/home/wayne/FGFS/osm2city-data"
OSM_FILE = "data.osm"

BOUNDARY_WEST = -97
BOUNDARY_SOUTH = 37
BOUNDARY_EAST = -96
BOUNDARY_NORTH = 38

NO_ELEV = False
ELEV_MODE = "FgelevCaching"
FG_ELEV = "/home/wayne/FGFS/install/flightgear/bin/fgelev"


This is the airport terminal that is not building completely, same minimal params (defaults)
KICT Wichita, KS
http://www.openstreetmap.org/way/93019351#map=18/37.65185/-97.42852

If you want me to run it with the changes you posted before you spend any time on it, I can do that. It'll be later today or tomorrow.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4880
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: osm2city.py development

Postby vanosten » Thu Nov 24, 2016 9:01 pm

The reason why I does not generate the airport terminal is that there are no suitable textures. This is an area, where a lot is left to do - especially having more and more diverse textures (in this case for terminal).

The reason why the small houses are not shown is simply due to their limited size. The following does the trick.
Code: Select all
BUILDING_MIN_AREA = 20.0
BUILDING_REDUCE_RATE = 0.01
BUILDING_MIN_HEIGHT = 1.0


In such situations I suggest that you do the following:
  • Export directly from OSM web-UI a minimal data set
  • Make a minimal params.ini file with just this small area
  • Run osm2city buildings.py and read the output. You would see that there is a statement about small buildings skipped respectively buildings skipped due to missing textures.

I used
Code: Select all
PREFIX = "TEST"
PATH_TO_SCENERY = "/media/sf_terrasync"
PATH_TO_OUTPUT = "/media/sf_fg_customscenery/TEST"
PATH_TO_OSM2CITY_DATA = "/home/vanosten/develop_vcs/osm2city-data"

FG_ELEV = "/home/vanosten/bin/fgfs_git/install/flightgear/bin/fgelev"
OSM_FILE = "foo.osm"

BOUNDARY_WEST = -96.8124000
BOUNDARY_SOUTH = 37.8004000
BOUNDARY_EAST = -96.7788000
BOUNDARY_NORTH = 37.8150000

NO_ELEV = False
FG_ELEV = "/home/vanosten/bin/fgfs_git/install/flightgear/bin/fgelev"

BUILDING_MIN_AREA = 20.0
BUILDING_REDUCE_RATE = 0.01
BUILDING_MIN_HEIGHT = 1.0
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 411
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby wlbragg » Thu Nov 24, 2016 11:34 pm

Thank you for all your help and advice for troubleshooting.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4880
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: osm2city.py development

Postby vanosten » Sat Nov 26, 2016 11:47 am

I have implemented overlap check for buildings and roads/railways against runways and helipads (not taxiways) based on apt.dat.gz in $FG_ROOT.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 411
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby vanosten » Sat Nov 26, 2016 2:58 pm

I have implemented a new parameter and code to let osm2city work nicely with Project3000. See this post in the Project3000 thread.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 411
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby wlbragg » Sat Nov 26, 2016 3:38 pm

The reason why it does not generate the airport terminal is that there are no suitable textures. This is an area, where a lot is left to do - especially having more and more diverse textures (in this case for terminal).


What can I do to force the terminals to build either permanently globally (as in fixing the problem throughout osm2city) or locally (just in my local instance)?
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4880
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: osm2city.py development

Postby vanosten » Sat Nov 26, 2016 4:14 pm

There are three things that can be done:
  • observe in the output of osm2city buildings.py which type of buildings are skipped due to missing textures - and then create textures, which suit the case. That is the best thing to do, but can be quite hard (e.g. a texture being suitable to the mentioned terminal with a difficult geometry and at the same time being ok for other terminals is difficult)
  • create a dump (like in one color) and large fall-back texture, that is used, when everything else fails. That reduces the number of skipped buildings, but at the same time increases the number of buildings looking odd.
  • Accept that terminal buildings are hard to handle in a generic way and at the same time are much more visible when missing. As a consequence: model it as a static model and submit the scenery model database. It might not take many hours to model something that by nature looks better than a osm2city approximation.

All three things can be tested locally.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 411
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby wlbragg » Sat Nov 26, 2016 4:44 pm

model it as a static model and submit the scenery model database.

That makes the most sense to me. But it would be nice to account for the thousands of terminals throughout the world scenery that are not static models in osm2city.

I've been wanting to model some of my local airport terminals anyway, thanks for reminding me!
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4880
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: osm2city.py development

Postby vanosten » Sat Dec 03, 2016 1:25 pm

I have implemented probing for water for roads/railways, so they are not displayed as being in the water (there is a difference between water boundaries in Flightgear and water boundaries in OpenStreetMap).
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 411
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby vanosten » Sat Dec 17, 2016 1:26 pm

I have been working a bit on the "infrastructure": as a proof-of-concept OSM data can now also be read from a PostGIS database. There is a new parameter USE_DATABASE, which by default is set to False.

If you are interested you can read the docs. Currently it only works for pylons.py. So my next task is to implement it for all other stuff starting most probably with buildings.py.

Why do this?
  • Storing data in a database makes some stuff easier - especially if thinking global OSM dumps and differential updates of OSM data
  • The current file based batch process is cumbersome. Rewriting the batch process based on data in a database will make a lot of stuff much easier - including batch processing across 1x1 degree areas. Also specific parameters for free-shaped polygon areas (instead of uniform per rectangular tile) is a future possibility.
  • Speed might or might not be faster. However given that much of the time is used on elevation probing the difference will not be crucial.

The current database implementation uses the database as a dumb datastore. That will have to be like that as long as reading form OSM-files needs to be supported in parallel (which will be the case for an unspecified amount of time.

For the rest of you: If you take new versions from git, then you have to add psycopg2 to your Python libraries/path. I am sorry.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 411
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby psadro_gm » Mon Dec 19, 2016 4:01 pm

vanosten wrote in Sat Dec 17, 2016 1:26 pm:[*] Speed might or might not be faster. However given that much of the time is used on elevation probing the difference will not be crucial.


I would love to know if elevation probing could be sped up using the experimental meshes I am creating.
The ultimate goal would be to perform all elevation probing at runtime, so we would only store offsets in the data.

Since it's always a regular mesh, the triangle can be looked up directly from lon/lat, then the elevation can be computed with barycentric coordinates. I expect it to be crazy fast :)
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 750
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: osm2city.py development

Postby Johan G » Mon Dec 19, 2016 5:33 pm

psadro_gm wrote in Mon Dec 19, 2016 4:01 pm:Since it's always a regular mesh [...] I expect it to be crazy fast :)

Ah! I wonder if that also will affect for example probing the terrain for use with terrain avoidance or navigation radars? :wink:
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5513
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: osm2city.py development

Postby vanosten » Mon Dec 19, 2016 5:56 pm

psadro_gm wrote in Mon Dec 19, 2016 4:01 pm:I would love to know if elevation probing could be sped up using the experimental meshes I am creating.
The ultimate goal would be to perform all elevation probing at runtime, so we would only store offsets in the data.


Sounds promising to potentially speed up elevation probing once your part gets closer to be the default for Terrasync. It is on my todo list to see what you are doing.

However I do not understand why doing elevation probing at runtime should be a goal. Until futher notice I assume storing a few bits of extra data to be worth it compared to doing calculations. Also the way osm2city scenery objects are planned to be (large meshes of hundres/thousands of e.g. houses in one ac.-file and therefore one entry in stg. it is at the point of creating the meshes that elevation probing needs to be done - not when used for the one centroid per mesh.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 411
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby psadro_gm » Mon Dec 19, 2016 9:19 pm

I want to keep the mesh separate from the landclass and vector data. I think it would be nice to be able to fix / replace mesh data without regenerating tiles again. For that to be possible, nothing would be pre-computed using the mesh.

We'll have to see how much faster elevation lookups are to see the feasibility, but I'm hopeful.

Also, I am hoping to be able to flatten the mesh at runtime as well. This is more of a stretch, I think, because it may require adding more points to the mesh. But being able to update OSM roads and be able to road-flatten without preprocessing would be great.

The main idea is to allow simple updates to scenery, without the need to re-process ALL of the data. Changing landclass would just affect the landclass raster. Changing mesh would just affect mesh raster. Pulling new airports would just affect the airport data ( which will just be 2-d layouts ). Pulling new OSM data just affects vector data, etc...

Pete
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 750
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

PreviousNext

Return to Scenery

Who is online

Users browsing this forum: MSN [Bot] and 8 guests

cron