Board index FlightGear Development Scenery

osm2city.py development

Questions and discussion about enhancing and populating the FlightGear world.

Re: osm2city.py development

Postby vanosten » Sun Feb 07, 2016 9:09 am

wkitty42 wrote in Wed Nov 11, 2015 9:32 pm:the thing that gets me most of the time is that these power pylons are simply too large... at least they look that way... especially when they are up near a bridge like around KSFO...


I guess that the transmission towers at KSFO are from Terrasync, so there the scenery database would have to be updated. For osm2pylon.py generated scenery objects you can specify
Code: Select all
C2P_POWER_LINE_ALLOW_100M = False
in your params.ini. Then the max height is 50 meters.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 540
Joined: Sat Sep 25, 2010 6:38 pm
Location: Denmark - but I am Swiss
Pronouns: he/his
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby pommesschranke » Tue Feb 09, 2016 10:01 am

Power pylons from Terrasync are usually 50m high.

I just read that in real life the usual height for a 110kV line is 22m and for 220kV it's 40m

you can copy the
Models/Power/generic_pylon_25m.ac model to the Models/Power/generic_pylon_50m.ac filename and see if that looks better for you.
pommesschranke
 
Posts: 1117
Joined: Sat Apr 27, 2013 8:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Kubuntu 22.04

Re: osm2city.py development

Postby vanosten » Fri Feb 19, 2016 9:32 pm

I have pushed a new version to Git. Main focus was re-enabling of railways plus a few more configuration options:
  • Parameter HIGHWAY_TYPE_MIN lets you configure which types of OpenStreetMap highways should be shown
  • Parameter POINTS_ON_LINE_DISTANCE_MAX makes it possible to add points on ways from OpenStreetMap. By doing so more elevation points are generated, which should help a lot removing residuals, when the scenery is uneven - e.g. in mountain areas.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 540
Joined: Sat Sep 25, 2010 6:38 pm
Location: Denmark - but I am Swiss
Pronouns: he/his
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby portreekid » Fri Feb 19, 2016 10:24 pm

Good work. I was always wanting to build POINTS_ON_LINE_DISTANCE_MAX. Will be most helpful
portreekid
 
Posts: 651
Joined: Tue Jan 14, 2014 4:36 pm
Location: Leipzig
Callsign: PORTREE
Version: 2020.2.1
OS: Windows 10

Re: osm2city.py development

Postby AlvA91 » Tue Feb 23, 2016 6:14 pm

Hi,

I have a short question: do you guys also have big stuttering with the scenery, like I do.

I have created the scenery for Grenoble (city and powerlines) and starting from the airport 'Le Versoud'. When I'm busy with, for example starting a helicopter, there are huge stuttering, because the OSM2CITY scenery gets loaded afterwards (while I'm already in the game, I can see how the buildings poping up later) and here it doesn't really bother me. But when I'm already in the air and I then turn the helicopter, there is again a huge stuttering (lag) and I nearly loose the control over my helicopter.

I have a Nvidia GTX 950 and a Intel Core I7 920 and 6 GB of Memory, but my hard disk is a simple SATA. I have the feeling, that the scenery is loaded from the hard disk when required and not safed in between, somewhere in the memory.

Is there a solution for this, or should I buy myself a SSD, can this maybe help.

Running FG in version 3.4 and have to keep this version for a few further month or even longer.

Regards
AlvA
AlvA91
 
Posts: 27
Joined: Wed Nov 04, 2015 12:22 pm

Re: osm2city.py development

Postby vanosten » Tue Feb 23, 2016 6:50 pm

There are two primary reasons why you might experience "stuttering":
  • If you have built a scenery, where the boundaries go across tiles (that is not likely a problem for the airport/Grenoble)
  • Your level of details settings are too narrow. It depends on what type of flying you do and your graphic card. I normally use detailed=5000, rough=10000 and bare = 15000.

You can read more about this in chapter 4 of the guide.

If that does not help, then please define "stuttering".
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 540
Joined: Sat Sep 25, 2010 6:38 pm
Location: Denmark - but I am Swiss
Pronouns: he/his
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby AlvA91 » Tue Feb 23, 2016 7:27 pm

Hi vanosten,

the hint with the level of details setting was really useful. Now the lags are reduced but still there. What do you mean with: 'the boundaries go across tiles'? Do you mean, that I set the settings in parameters.py (BOUNDARY_WEST, BOUNDARY_EAST...) wrong, or do you mean smth else?

Regards
AlvA91
 
Posts: 27
Joined: Wed Nov 04, 2015 12:22 pm

Re: osm2city.py development

Postby alge » Tue Feb 23, 2016 10:39 pm

Hey Vanosten, your recent change related to enums breaks things here on my ubuntu 15.04 box. After installing the "python-enum34" package it works again. The wiki page says "enum34", not "python-enum34", though.

Aaalso, you did a booboo when adding the tram / light_rail in create_linear_object, because you forgot to add them to max_slope_for_road as well. This fixes it:

Code: Select all
diff --git a/roads.py b/roads.py
index 0c6a57e..1cd67e2 100755
--- a/roads.py
+++ b/roads.py
@@ -260,7 +260,7 @@ def max_slope_for_road(obj):
         else:
             return parameters.MAX_SLOPE_ROAD
     # must be aligned with accepted railways in Roads._create_linear_objects
-    elif 'railway' in obj.tags and obj.tags['railway'] in ['rail', 'disused', 'preserved', 'subway', 'narrow_gauge']:
+    elif 'railway' in obj.tags and obj.tags['railway'] in ['rail', 'disused', 'preserved', 'subway', 'narrow_gauge', 'tram', 'light_rail']:
         return parameters.MAX_SLOPE_RAILWAY
 



Other than that.. great work! The last changes really helped in my slighty-hilly city!
alge
 
Posts: 77
Joined: Thu Aug 30, 2012 1:45 am

Re: osm2city.py development

Postby AlvA91 » Tue Mar 08, 2016 12:10 pm

I solved my problem mostly, it didn't had to do anything with osm2city. It was the combination of the 'texture compression' option and my Nvidia driver that caused this problems.

I just write it down here to tell you, that my question is solved ;)
AlvA91
 
Posts: 27
Joined: Wed Nov 04, 2015 12:22 pm

Re: osm2city.py development

Postby vanosten » Sun Mar 13, 2016 11:15 am

I have made some updates to batch processing, such that it is possible to use existing downloaded OSM-files and use Osmosis to split them up in batch mode. That might help those of you, who experience challenges with dynamic downloads and/or want to process OSM data before they are used in osm2city. Documentation has been updated.

The newest version of the manual in pdf-format can always be found at https://gitlab.com/fg-radi/osm2city/blob/master/doc/manual/osm2city.pdf.
An offline version in html can be found on Dropbox.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 540
Joined: Sat Sep 25, 2010 6:38 pm
Location: Denmark - but I am Swiss
Pronouns: he/his
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby pommesschranke » Sun Mar 13, 2016 12:02 pm

Thank you !
I use batch processing a lot.
I recently made this little wrapper for it:
https://github.com/mherweg/d-laser-fgto ... wrapper.sh

can you maybe fix the texture-bug on big flat roofs ?
I tried it already but had no success. :-(

I suggest to make an extra tillable roof.png or scale the UV coordinates
to make sure to have no wall-texture on the roof.
pommesschranke
 
Posts: 1117
Joined: Sat Apr 27, 2013 8:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Kubuntu 22.04

Re: osm2city.py development

Postby vanosten » Mon Mar 14, 2016 7:08 pm

pommesschranke wrote in Sun Mar 13, 2016 12:02 pm:can you maybe fix the texture-bug on big flat roofs ?
I tried it already but had no success. :-(

I suggest to make an extra tillable roof.png or scale the UV coordinates
to make sure to have no wall-texture on the roof.


I understand your request and have also seen "annoying" artefacts. Unfortunately I believe that you need to wait until user radi has time - I have not yet bothered learning the whole texture stuff. Also my personal next goal is still to upgrade all modules to Python 3.x (batch processing only being a means to provide "automatic testing" for the upgrade).

PS: the -o option is not mandatory anymore. Your requirements might be special (please share them, so we can do something about it in parameters.py), but it is a bit unusual to have a need for special params.ini file for roads respectively osm2city in your shell script.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 540
Joined: Sat Sep 25, 2010 6:38 pm
Location: Denmark - but I am Swiss
Pronouns: he/his
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: osm2city.py development

Postby portreekid » Mon Mar 14, 2016 9:47 pm

pommesschranke wrote in Sun Mar 13, 2016 12:02 pm:can you maybe fix the texture-bug on big flat roofs ?
I tried it already but had no success. :-(

I suggest to make an extra tillable roof.png or scale the UV coordinates
to make sure to have no wall-texture on the roof.


unfortunately I haven't delved into the depths of textures either. The artefacts also appear on gabled roofs if they are larger, since it seems that roofs are never tiled.
portreekid
 
Posts: 651
Joined: Tue Jan 14, 2014 4:36 pm
Location: Leipzig
Callsign: PORTREE
Version: 2020.2.1
OS: Windows 10

Re: osm2city.py development

Postby pommesschranke » Mon Mar 14, 2016 11:35 pm

vanosten wrote in Mon Mar 14, 2016 7:08 pm:PS: the -o option is not mandatory anymore. Your requirements might be special (please share them, so we can do something about it in parameters.py), but it is a bit unusual to have a need for special params.ini file for roads respectively osm2city in your shell script.


I want to make sure that roads & buildings end up in 2 different scenery folders.
pommesschranke
 
Posts: 1117
Joined: Sat Apr 27, 2013 8:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Kubuntu 22.04

Re: osm2city.py development

Postby vanosten » Sun Jul 03, 2016 7:45 pm

I have started looking into the textures code. Currently it does not make sense to re-create the textures often - and therefore I have removed the -A option from osm2city and removed the parameter CREATE_ATLAS altogether. The documentation is updated.

I consider changing the python based texture configuration with a set of csv-files (one for roofs and one for facades). It might be a bit less flexible, but it is much easier to edit in e.g. a spreadsheet program and do filtering. If there would suddenly be momentum with people providing more textures, then we will take more requirements into account at that point. I will also update http://wiki.flightgear.org/Osm2city.py_Textures.

For those of you, who have screenshots of roofs not being textured correctly: please provide a link to pictures. I will try to explore.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 540
Joined: Sat Sep 25, 2010 6:38 pm
Location: Denmark - but I am Swiss
Pronouns: he/his
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 8 guests