Board index FlightGear Development Scenery

osm2city.py development

Questions and discussion about enhancing and populating the FlightGear world.

Re: osm2city.py development

Postby merspieler » Thu Apr 30, 2020 7:12 pm

vnts wrote in Thu Apr 30, 2020 1:26 pm:What do you estimate the compressed download size, and uncompressed size (~5.8x download size?), to be when it's done?


I'd say certainly less than 150GB for download... maybe about 700GB uncompressed.

You should probably let Torsten know, and if there are no no other blockers, then it's upto C++ side (Stuart..) and OSM2City side (Vanosten..) on how/when to proceed(?).


Stuart knows... But there hasn't been a move on his side... from my side, everything is done... just needs to be copied into ts.

- People using previous versions? 2018.3 and earlier doesn't accidentally download building lists & crash. Will 2019.1 with it's slightly buggy building shader be served OSM2City?


It shouldn't be downloaded by ts in the first place... even if it does... the files are zipped -> don't get loaded -> no crash.

- Versioning plans for building lists? Mentioned in this post (link). There are one or two optional/bonus bits of data which ([url=https://forum.flightgear.org/viewtopic.php?f=5&t=22809&start=1215]link[/link], for example, might help with making L, U, or more complex shaped buildings with compatible roofs out of rectangular buildings in a way that works well with future iterations. These could be added later too if the list file format is made extensible/backwards compatible.


Don't ask me about such changes. If this kind of change comes with other improvements which I consider worth a rebuild, I'll rebuild the globe (or if I get payed to do so ;-) ).

- There's was/is(?) a lack of a host for the combined landcover data set. (Once this is solved, there might be a manual way to contribute to a best-of-all-sources landcover database??)


There is a host (me) but I haven't yet recived the data as Torsten has currently no access to the machine, where the files are stored... and probably won't get to it soon due to the Cortana-Virus.

You should possibly mention these stats in the mailing list as an available option for doing regular terrain builds.


I've offered the server capacity to selected individuals for use. Apart from hosting so far only frtps has taken that offer and uses it for the australian scenery build.

Google are the type of company that may possibly help out, as Flightgear is a volunteer project that benefits the public good, and it's an insignificant amount of cloud server time for terrain builds or hosting space for them. The big benefit of striking an official relationship with google might be that FG gets access to bits of their streetview photo database (and maybe any close-up aerial images they own rights to for terrain textures). The idea being that FG could upload some extracts with trees (or maybe buildings) into a repo, and google signs off periodically (e.g. every 3 months) releasing the content into GPL2+. Google generally likes opensource. The reason for their restrictive license is seemingly mainly so it doesn't enable a competitor to run a rival service using their collected data. Flightgear's use is only a few bits of images for textures, so they can't be hurt financially. It may be something worth trying out.


I'm not stopping you... just that you know, as far as I'm aware of, google doesn't own it's aerial footage but gets it from other sources like ESRI.... just that you don't put too much hope into that.

I won't spoil too much but as soon as we have some kind of support in fg to easily add photo scenery (without the need to patch and rebuild from src) I'll be setting out for a photo worldbuild (#GlobalSelfie).
Love at first flight A<380
Attempting an osm2city worldbuild... Coming to YOUR terrasync....... when ever they start pulling it in, so go nag them on the mailing list (I totally didn't say that)!
merspieler
 
Posts: 696
Joined: Thu Oct 26, 2017 10:43 am
Location: Wish to be in YBCS
Callsign: JST935. ORI1711
IRC name: merspieler
Version: next
OS: Debian Bullseye

Re: osm2city.py development

Postby montagdude » Fri May 01, 2020 2:00 am

I have another quick and hopefully easy question. Let's say for my custom scenery I need to fix a small error, like a missing airport or a problem with one of the landclass shapefiles. If I make those changes and run tg-construct again but leave the SRTM-3 work directory intact, will the resulting terrain have the exact same elevation? Or in other words, will I have to re-run the osm2city scripts for my custom scenery after making a change like this? tg-construct for my custom scenery will finish overnight, but running osm2city again would take several days.
montagdude
 
Posts: 225
Joined: Tue Dec 31, 2019 6:04 am

Re: osm2city.py development

Postby frtps » Fri May 01, 2020 10:16 am

Elevation is calculated for each vertex in the terrain after the terrain has been clipped, assembled and tesselated. So what that means is that if a vertex changes position, or a new vertex is introduced, a new elevation will be calculated. However, the elevation is interpolated from exactly the same grid so the new elevation should be close to the elevation that that appeared at those coordinates previously, especially if were a lot of nearby vertices already. It probably also depends on the tolerance you used for the 'terrafit' step, this tolerance will be roughly equal to the maximum error you will encounter when adding vertices.
frtps
 
Posts: 112
Joined: Sun Aug 05, 2018 9:58 am

Re: osm2city.py development

Postby montagdude » Fri May 01, 2020 11:53 am

frtps wrote in Fri May 01, 2020 10:16 am:Elevation is calculated for each vertex in the terrain after the terrain has been clipped, assembled and tesselated. So what that means is that if a vertex changes position, or a new vertex is introduced, a new elevation will be calculated. However, the elevation is interpolated from exactly the same grid so the new elevation should be close to the elevation that that appeared at those coordinates previously, especially if were a lot of nearby vertices already. It probably also depends on the tolerance you used for the 'terrafit' step, this tolerance will be roughly equal to the maximum error you will encounter when adding vertices.

Okay, I think I've got it. Does that mean there would only be any elevation changes in the areas where the underlying data (landcover shapefiles, airports, etc.) changed? Everywhere else would be identical, even if I run tg-construct again for the entire custom scenery?
montagdude
 
Posts: 225
Joined: Tue Dec 31, 2019 6:04 am

Re: osm2city.py development

Postby frtps » Fri May 01, 2020 12:27 pm

Yes, definitely only in the very specific area where you have changed landcovers would there be any small change in elevation. Any vertices that existed before your change and that have unchanged location will be given identical elevations.
frtps
 
Posts: 112
Joined: Sun Aug 05, 2018 9:58 am

Re: osm2city.py development

Postby vnts » Fri May 01, 2020 1:48 pm

@Merspieler thanks for info, things seem set to progress :)
Michat wrote in Tue Apr 28, 2020 6:52 pm:Thanks for the info.
I have modified the atlas texture, however as I don't have PC to run FG I didn't test such texture.
This is the link to the texture, in which I changed roofs color and modified building texture (Sun bright spot). Texture's name after edition is atlas_facadesmio.png
https://www.photobox.co.uk/my/photo/full?photo_id=502933244263

I wish someone could test it and show me a picture, please.

EDIT. link to the texture https://serving.photos.photobox.com/934116707451c11ef96036322805e9009084f0bbf1c630c68f8c6f0a3d60301542116996.jpg Note that the service I'm using changes the extension to .jpg so it isn't the best to use.

The link works now: )

Modified & original: album

Greens & blues are gone :D

AIUI the jpg file needs to be converted to png anyway for it to load, or filename in the relevant effects or materials needs to be changed to match. Maybe cubeupload.com or uploading a zip file will not change file type.

The modified version seems to have been rescaled down. Dimensions aren't a power of 2? Some wall textures at top are missing. Intentional?
Modified:240 × 15360, Original:256 × 16384

Original (left), and rescaled modified (right) roof/wall part of atlas: image.

Some of the new roof textures are flat colours with no large scale detail (can makes colour look a bit flat / artificial). By larger scale I mean detail like weathering, rust/algae/stains large scale roof details. Small scale details like tiles blend into the average colour as the camera moves back e.g. a brick pattern will blend into a flat reddish colour. The large scale detail is what people see first as they approach, then they see smaller scale detail if they fly lower/closer.

One trick which works to transfer existing large scale detail is using gimp's menu->colours->map->rotate colours tool to map one hue range to another. I used the dark brown colour (image) you chose for the original cyan roof (image) then rotated colours to map cyan to brown. Then reduced the brightness a bit to match your colour: result.

(less related aside, not specifically for Michat: Something that would be useful for shader buildings and other things like soil colours, is a fast shader way to do the rotate colours operation without doing the full colourspace change. Change hue without affecting saturation (weathering detail), or intensity (surface detail). Haven't been able to find a way. The rest seems doable. It's possible to identify different hues with a table (array) that gives info like the range of hue values. For each texture, people can just set a list of possible destination hues to randomly map the primary and secondary colours (hues ranges) to in regional definitions. The shader can then randomly choose between destination hues. People can specify 0-1 subranges within each hue too like reddish brown. e.g. mapping a reddish roof hue to common colours for that region: yellow, reddish part of the brown range, orange, etc.)

Some of the modified textures have large scale detail, but it is very faint(?). Not sure that detail can be noticed. Increasing contrast or darkening dirt/lines might help large scale detail stand out. Some textures for wall texture slots have less weathering, and less contrast (less darker lines) than originals. (Changing the normal map with roof tile or brick pattern is probably very effective too, but it's a different, more complex, operation.)

Kind regards
vnts
 
Posts: 213
Joined: Thu Apr 02, 2015 12:29 am

Re: osm2city.py development

Postby vanosten » Fri May 01, 2020 3:07 pm

Please understand that changing the texture is a temporary fix for a given situation. I am currently implementing a better workaround to reduce the glass and grass roofs to much less usage. That will not help with existing sceneries, but with future sceneries (until there is a new texture atlas - which is not done by changing the existing one).
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 473
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 merspieler » Fri May 01, 2020 3:29 pm

vnts wrote in Fri May 01, 2020 1:48 pm:@Merspieler thanks for info, things seem set to progress :)

Set for progress yes... actually progressing, no.
Love at first flight A<380
Attempting an osm2city worldbuild... Coming to YOUR terrasync....... when ever they start pulling it in, so go nag them on the mailing list (I totally didn't say that)!
merspieler
 
Posts: 696
Joined: Thu Oct 26, 2017 10:43 am
Location: Wish to be in YBCS
Callsign: JST935. ORI1711
IRC name: merspieler
Version: next
OS: Debian Bullseye

Re: osm2city.py development

Postby vanosten » Thu May 07, 2020 7:51 pm

I have done some changes during the last few days to improve some issues:
* Glass and grass on roofs are now only used if tagged as such in OSM.
* On buildings with many levels there are no more gabled roofs
* More building relations detected by geometry (no OSM tagging) -> buildings composed of several parts should now have higher probability to get same texture.
* Gabled roofs of buildings with neighbours are now more aligned. I hope to find a somewhat easy way to align more building roofs around a corner.

When all this is said: I made many changes and have only tested so much.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 473
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 montagdude » Thu May 07, 2020 7:53 pm

Those sound good! I'll test them out when I get the chance. Might not be for a little while, though.
Last edited by Johan G on Thu Jul 09, 2020 3:45 pm, edited 1 time in total.
Reason: Please, do not quote the entire post directly above your post.
montagdude
 
Posts: 225
Joined: Tue Dec 31, 2019 6:04 am

Re: osm2city.py development

Postby Michat » Fri May 15, 2020 4:31 pm

I've edited the atlas_facades.png removing water colors on roof., Sun reflecting on a skyscrapper, dark black building tops, adding some new colors here and there.

We have test it out with user Miguel with positive feedback.

Is time for you to test it and tell me your opinion with sharing screenshots..

The edition has been made with Inkscape, the skill used allows to change colors easily. So if you spot any mistake just report a picture, so we can improved it.

Image

29.92
Last edited by Michat on Mon Jun 01, 2020 5:02 pm, edited 1 time in total.
User avatar
Michat
 
Posts: 1041
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: osm2city.py development

Postby Michat » Sun May 24, 2020 7:30 pm

Picture showing Atlas facades texture at Sidney. Courtesy of Miguel and big applause for the developers.

Image


29.92
User avatar
Michat
 
Posts: 1041
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: osm2city.py development

Postby wlbragg » Mon May 25, 2020 2:59 pm

Outstanding work folks. Looking really good!
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 5684
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: osm2city.py development

Postby montagdude » Tue May 26, 2020 12:45 pm

It looks fantastic. Are these new textures in osm2city master?
montagdude
 
Posts: 225
Joined: Tue Dec 31, 2019 6:04 am

Re: osm2city.py development

Postby Michat » Tue May 26, 2020 5:06 pm

Negative. That texture, my humble edition of the atlas_facades bitmap is not in osm2city master. Is just a testing edition attempting to remove green and blue roofs. Things that I was able to achieve. However, today I've notice that, if we look at the picture provided by Miguel, there are a few tall buildings facades that are covered with "roof colors". So as user VTNS said we should to split it out, or just in this case find and change those tall buildings definition-relation with the target segment map of the atlas facades texture to mach an entired satisfactory result for all the buildings. ( out of my scope )

So I encourage FG users to test, report and suggest for any improvement needed.

29.92 Thank you.
User avatar
Michat
 
Posts: 1041
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

PreviousNext

Return to Scenery

Who is online

Users browsing this forum: No registered users and 4 guests