Board index FlightGear Development Scenery

osm2city.py development

Questions and discussion about enhancing and populating the FlightGear world.

Re: osm2city.py development

Postby Johan G » Thu Nov 10, 2016 7:17 pm

vanosten wrote in Thu Nov 10, 2016 6:40 pm:There has been some discussions on the fg-devel list recently about the future of osm2city, which I had the pleasure to talk about with some of the core developers..

The high level idea is as follows:
[...]

[...] the hope is that osm2city generated scenery will become much more accessible to the average FlightGear users [...]

Done right this is a big thing. :D (So take your time. :wink: )


Side note:

Learning to contribute to OSM is for most people likely easier than learning to use Blender or editing and generating terrain (though both will still be needed).

The learning curve for the JOSM editor (Java OpenStreetMap editor), which I highly recommend, is not all that big (in particular if one have experience with GIS software, though the terminology differs slightly from the regular one).
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: 5490
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 » Sun Nov 13, 2016 6:36 pm

pommesschranke wrote in Sun Sep 11, 2016 7:04 pm:
radi wrote in Wed Sep 07, 2016 12:23 pm: change the dimension of ALL roof textures to something huge, e.g. 400x400m. This should get rid of most/all roof bugs.


I did. And it works! :D
Thank you very much!


I have pushed a new version of osm2city and osm2city-data. Together I hope this will solve many of the texture problems on large roofs. Basically I fixed situations, when the roof during analysis was set to be complex - and then later set back to flat -- which resulted in wrong roof textures being chosen. And then I have added compat:roof-large to signal that a specific roof texture can be used on large roofs. Plus I took an existing roof and just stretched it, so we have a fallback.

I hope this solves many cases. Just post screenshots and lon/lat plus osm_ids of buildings, where it does not work nicely.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
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 litzi » Mon Nov 14, 2016 9:34 pm

First of all, congratulations for this awesom project that really, at least for me, brought flightgear to a new dimenson in terms of "immersion" factor!

I tried it out on my "local" neighbourhoods scenery (near LOWW) and compared to the original osm rendering (see osmbuilding.org) I identified minor issues with length units parsing and with roof orientation parsing in the code. Can I report these as issues to the gitlab repo?

Secondly I would be interested to know if there are any plans to implement support of "detailed" osm buildings, such as this example (https://osmbuildings.org/?lat=48.12373&lon=16.56103&zoom=18&rotation=-29&tilt=42)? Currently, IMHO the relations of type="building" containing members with roles {outline, part, part, ..., part } are not correctly processed by osm2city.

litzi
litzi
 
Posts: 72
Joined: Sat May 03, 2014 8:59 pm
Location: AT
Version: 2018.3.1
OS: Ubuntu 14.04

Re: osm2city.py development

Postby Johan G » Mon Nov 14, 2016 10:27 pm

litzi wrote in Mon Nov 14, 2016 9:34 pm:Secondly I would be interested to know if there are any plans to implement support of "detailed" osm buildings [...] ? Currently, IMHO the relations of type="building" containing members with roles {outline, part, part, ..., part } are not correctly processed by osm2city.

You mean like described in this article on the OpenStreetMap wiki: Simple 3D buildings (perm)?

That could be a texturing challenge I guess, even though there are tags like "building:colour=*", "roof:colour=*", "building:material=*" and "roof:material=*" (click on the taginfo link at the bottom of the infoboxes to see actual values, like roof:material=<values>).

Hmm, see also the OSM wiki article 3D development (perm) for other software that uses OSM 3D data.
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: 5490
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 radi » Tue Nov 15, 2016 2:38 am

While the example litzi referred to looks great, it not only represents a texturing challenge, even creating a proper mesh for these cases is currently way beyond the scope of the project.
OSM buildings for LOWI, EDDC
Custom scenery for VHXX YMML
Edit .stg via the FG Object Placement Tool
radi
 
Posts: 641
Joined: Mon Aug 25, 2008 4:24 pm
Location: YMML, EDDC

Re: osm2city.py development

Postby litzi » Tue Nov 15, 2016 8:16 pm

Yes, I am referring to the "simple" 3d buildings of osm.

I could try something and will come back to you if I can come up with something useful.

litzi
litzi
 
Posts: 72
Joined: Sat May 03, 2014 8:59 pm
Location: AT
Version: 2018.3.1
OS: Ubuntu 14.04

Re: osm2city.py development

Postby wlbragg » Wed Nov 16, 2016 3:15 am

I decided to update some of my custom osm2city scenery.

I am on a new Linux Debian install and current osm2city files.

It has been so long since I did this before I had to basically start from scratch.
However I had some historical custom instruction I wrote and saved and also the original params.ini I used.

I am running into one hurdle after another and I am wondering if maybe my "default Debian install" python version is causing issues.

EDIT:

Any ideas what I have wrong or am doing wrong?

My Debian installation is using Python 2.7.9.

I noticed the version this is all built on is 3.6, wow, Debian is REALLY slow in updating packaging. I'll update and see if that fixes some of this.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4824
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 » Wed Nov 16, 2016 6:17 am

Hi

I am guilty in not having updated the documentation the last two weeks. Apart from elevation probing, which now is exclusively FgelevCaching, the rest of the documentation on osm2city.rtfd.io is still valid. Comments to the documentation are welcome.

While you are updating your Debian: please note the extra packages needed in their Python 3 version as described in the docs.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
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 rominet » Wed Nov 16, 2016 7:50 am

wlbragg wrote in Wed Nov 16, 2016 3:15 am:My Debian installation is using Python 2.7.9.

I noticed the version this is all built on is 3.6, wow, Debian is REALLY slow in updating packaging. I'll update and see if that fixes some of this.

Debian has Python 3.5.2 on unstable and 3.4.2 on stable. Maybe you are confusing the python package (which is Python 2.x) and the python3 package (which ships Python 3.x)? The same goes for the command name:
  • python runs Python 2.x
  • python3, python3.x (e.g., python3.4 or python3.5) run Python 3.x (python3 runs the “default Python 3 interpreter”).
This is to avoid breaking compatibility with Python 2.x scripts, which traditionally used to start with:
Code: Select all
#! /usr/bin/env python

or:
Code: Select all
#! /usr/bin/python

where the former finds the 'python' executable in the PATH, while the latter uses a hardcoded location.

Edit: add some precisions.
rominet
 
Posts: 557
Joined: Sat Nov 01, 2014 1:33 pm
Callsign: F-KATS
Version: Git next
OS: Debian GNU/Linux

Re: osm2city.py development

Postby wlbragg » Wed Nov 16, 2016 7:11 pm

I noticed the version this is all built on is 3.6,

I meant 3.5, typo.

Here is where I am at after a few hours of configuring.

I am stuck on Numpy and typing

I have Numpy installed and in the environment on python 3.4, i cant seem to get it installed on python3.5. So I am OK with building osm2city on python3.4. But, now I get stuck on typing, it sounded like typing is installed by default on python3.5 but not on python3.4. I am admittedly not the most versed in Linux system configuration.

Am I making this more difficult than it needs to be?

What started all of this is my default Debian installation was on python2.7.? so I installed 3.5. Where 3.4 came form is beyond me. I just noticed it was there after I installed Numpy using python3 which I am pretty sure maps to 3.5. python --version reports 3.5. I use python3.4 to get past Numpy and break on "typing". I use python3 = 3.5 and break on Numpy.

Windows was actually easier to set up last time I tried this, that's got to be a first :lol:
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4824
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 » Wed Nov 16, 2016 7:28 pm

You need to use Python 3.5 - due to "typing". It makes a huge difference for me as a programmer to be able to specify type hints - especially being part of a team and therefore reading others' code. I am sorry for your troubles.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
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 » Wed Nov 16, 2016 7:45 pm

And the documentation is up to date again (shorter due to fewer choices for elevation probing).
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
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 » Wed Nov 16, 2016 8:07 pm

OK, 3.5 it is.

Time goes by....

So I decide to try to install Numpy over python3.5 one more time. It goes through the install process and I run build_tiles.py and guess what, it magically works. All it took was griping to you all, thanks!
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4824
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 wlbragg » Thu Nov 17, 2016 12:03 am

Time passes...

Yes, still trying to get my environment in order. I finally got past the system dependencies and let me tell you, a default Debian installation is not configured to work with the osm2city docs, not even close. Everything from having to install python3.5 and at least 3 or 4 dependencies not listed in the osm2city docs. I wish I could have documented it and helped with the docs, but it was all I could do just to navigate through it.

Long story short, I am really close but just got stuck on a osm2city script issue.
Code: Select all
INFO:root:Loading /home/wayne/FGFS/osm2city-data/tex/atlas_facades.pkl
Traceback (most recent call last):
  File "/home/wayne/FGFS/osm2city/buildings.py", line 488, in <module>
    prepare_textures.init(args.create_atlas)
  File "/home/wayne/FGFS/osm2city/prepare_textures.py", line 291, in init
    facades = pickle.load(pickle_file)
AttributeError: Can't get attribute 'FacadeManager' on <module 'textures' from '/home/wayne/FGFS/osm2city/textures/__init__.py'>

This is during ./buildings_w095n36.sh Any idea what it wants?
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4824
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 17, 2016 3:13 pm

As a sidenote: please make sure also to update osm2city-data from git.

You need to run prepare_textures.py manually once before running the sh scripts. Most probably you have an old pkl file in osm2city-data/tex, which contains a different objectstructure compared to the newest code.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

PreviousNext

Return to Scenery

Who is online

Users browsing this forum: No registered users and 1 guest