Drawing coastlines

The rivers are also an issue for me there are many oueds in Afnor and they are often in very closed valley or canyons I think I will use these fsuipc way that's could be a funny challenge,that will need also a special texture ,a new vtp1 lines for the dry parts of these rivers ,you could , about your beachs ,create two differents lines or a new one keeping the default and your new with wave adding that in the g2k ownlines.txt ant put this bmp texture in ....Yourscenery\texture and in your ...world\scenedb\texture to make it appear in g2k dialog box, anyway the stocks default cfs2 lines are too few we need to add some if we want get some variations in the shores and ways lines .
I think about the Xavier's airfield the corrections could be done with bgl analyse (bgl-->Scasm txt altitude corrections, etc... --> bgl ),and adapting the backgd landclass or perhaps also in altering the alpha channel ...

JP
 
... drawing more accurate rivers in G2K

Trying to fly CFS2 in 256 colour mode so I can use G2K is a hoot! :icon_lol:The pixellation is so bad you can hardly tell where the terrain lies ....:pop4:

I found a partial workaround. Not perfect, but pretty close.

I used Microdem to open the SRTM geotiff.

Amongst the amend/ edit options you can choose "elevations"

One of the colour options is 25 or 45 colours. Choose either of these (depends on the hillyness of the terrain) & then save the amended as a bmp.

The bmp will now show in G2K. Colour banding helps in reading the terrain. Still have detail placement issues, but that's because the background bmp moves around as you force redraw because you've scrolled onto a new screen area.

What I do is to draw the rivers using a map background, then reload G2K using a this terrain bmp as background, & adjust the position/ placement of the rivers accordingly.

Not perfect result, but most of what I've seen so far is as much to do with the line width & line bmp "wiggle" as anything.

:mixedsmi:
 
now we can post screenshots once more ...

I think it's pretty much complete.

I tried drawing some offshore whitecaps & decided it would require too much reworking to match & blend with the waterclass work so I removed them again.

Some screenies follow
 
I decided to do the Nicobars in the same style, to complete the island group.

For info., this will complete all the island groups in SRTM55_10 & SRTM55_11.

I'll then upload as a single pack, as they share texture sets.

Possible follow ons:

Airstrips
Would be nice to have an airstrip on Car Nicobar - does anyone know if one has been done before?

I have Xavier's strip at Port Blair, but if I need to learn how to do modify his entry so it blends with the texture set better. The infrastructure needs to be repositioned to match the new coastlines also.

GSL work
At some stage this whole island chain needs some gsl work - lighthouses, piers etc.
 
...
. The infrastructure needs to be repositioned to match the new coastlines also.
....
May I suggest you adjust the coastline to match Xaviers field; moving the GSL is going to be really difficult and annoying for the end users; just see how complicated it was when the stock airfields didn't match with Rhumba's new water. Also if missions were developed for those fields, you will break those if you move the actual airstrip; just changing the airbases.dat is not enough, the coordinates are in the mission file as well.
 
I don't mean the airfield coordinates, it sits just fine (flatten excepted), but there's a bgl for Port Blair that has a couple of pillboxes out in the bay.

Seems a shame to lose all Rhumbas fine work with the world mesh by adjusting the coastlines to suit the old (inaccurate) scenery though ...
:crybaby:

how many missions could it affect - it's not like it's Henderson Field?
 
....
Seems a shame to lose all Rhumbas fine work with the world mesh by adjusting the coastlines to suit the old (inaccurate) scenery though ...
:crybaby:...
Ummm Rhumba's new water is not to accurate either.... (the mesh is ok, but the LWM is too wet)
Anyway, "accurate" is extremely subjective for a historic sim such as this. The SRTM we now use is from the last decade. A lot of the world has changed considerably since the 40's, through global warming, erosion, reclaiming/building (I'm from Holland; a whole province where 1 million people now live was still water in 1945!)
 
Sander's right.

The water files I made are too wet in many areas. I used Jim Keir's Slartibartfast ( and raster images of the SRTM water body data ) to make the LWMs, and the control of the water is too "loose" when making huge areas. The closer we look, the more apparent it becomes we have no accurate source for LWM.

I don't think sea level and erosion has changed too much of the planet, but man-made coast alterations have occured and volcanoes have changed some coastline areas. I think Rabaul, New Britain was destroyed by a volcano, and a mountain now sits on the old runway, and the coast was also changed in that area.

The mesh I made is OK for most of the planet. We need to hand-draw new water, if we want accuracy. We need to draw our own from either LandSat7 images, or newer images available from Google or Bing! or Yahoo. And this hand-drawing will take a lot of time for rather small areas. Just an LOD5-sized area could take several days.

I think my mass-produced water is better than the default, but it is still not as good as we can get it.

I looked at some commercial samples of waterbody data, and they are just the same old saw-toothed SWBD files cleaned up a bit. There are some commercial data that was used for the FS9 and FSX Ultimate Terrain that's very nice, but it is also very costly.

Dick
 
OK, I understand, but what's the point of all this work if we need to create fresh polys (which I did do for the Andaman chain), only to then have to fudge the coastlines to make use of the "old" gsl work.

It sounds like we're advocating that it's better just to adding coastlines & a bit of landclass/ waterclass (maybe) over the existing cfs2 scenery?

I'm not sure that is what any of us mean ...
 
Sander's right.

The water files I made are too wet in many areas. I used Jim Keir's Slartibartfast ( and raster images of the SRTM water body data ) to make the LWMs, and the control of the water is too "loose" when making huge areas. The closer we look, the more apparent it becomes we have no accurate source for LWM. Dick

For what it's worth, I found whilst working that the black "0" elevation in the geotiff did more closely match the mesh than the SRTM waterbody images, which seemed too "aggressive". So, if we're looking to use Rhumbas mesh, a raster image of the black selected from each SRTM geotiff might do the job quite well...
 
I don't mean the airfield coordinates, it sits just fine (flatten excepted), but there's a bgl for Port Blair that has a couple of pillboxes out in the bay.
.......

Hi uncle
You can change the altitude of the flatten,by disassembling the airfield a16n bgl ,
you need BglAnalyze
http://www.scenery.org/design_utilities_a.htm
and SCASM exe that you have in your g2k folder
disassemble the a16n bgl or the airfield bgl if you have only one for it,you will get a text .sca , in you will find a paragraph about the a16nflatten ,it's possible to change also the location and some other things....
look in red the altitude
; ----------------------------------------
; Lartigue40 NS.BGL disassembled by BGLAnalyze (c) on Tue Mar 09 17:27:00 2010
; ----------------------------------------
Header( 1 N35:35:02.67 N35:29:38.69 W000:28:28.69 W000:35:06.83 )
LatRange( N35:29:38.69 N35:35:02.67 )
; since SCASM does not support multiple latitude ranges
; the range has been set to the minimum/maximum latitude.
; LatRange information in the BGL file is given as comment.
; If you want to use band separation, you must edit
; the source file manually.
; Insert the "Set( FSVers 0x800 )" instruction at the beginning
; of the file, if you want to use the FS2002 instructions
; for the facilities section
mif( [$Version < 285] )
Error( You need at least SCASM version 2.85 to compile this code )
mifend
; ----------------------------------------
; Procedural scenery
; ----------------------------------------

; LatRange( N35:29:37.75 N35:34:52.89 )
; ----------------------------------------
; ----------------------------------------
; Object # 1, offset: 0x000A size: 152 bytes (0x0098)
;; Lat: 0003C446Eh Lon: 0FF9F2103h
; ----------------------------------------
Area( B N35:32:27.18 W000:31:55.66 40 )
RefPoint( rel : 1.00 N35:32:27.18 W000:31:55.66
V1= -25936 V2= 3960 )
LoadBitmap( 0 5 F0 0 0 0
lartigue_wa.bmp )
Smoothing( 1 )
Points( 0
-1400 0 -1400 ; 0
1400 0 -1400 ; 1
1400 0 1400 ; 2
-1400 0 1400 ; 3
)
TexPoly( m 0 32767 0 0
0 0 0 ; 0
3 0 255 ; 1
2 254 255 ; 2
1 254 0 ; 3
)
ZBias( 0 )
Smoothing( 0 )
EndA
; ----------------------------------------
; Object # 2, offset: 0x00A2 size: 360 bytes (0x0168)
;; Lat: 0003C42E0h Lon: 0FF9F924Dh
; ----------------------------------------
Area( 5 N35:32:14.28 W000:31:46.91 20 )
IfVarRange( :L0000C8 037E -20 20 )
IfVarRange( :L0000C8 0386 -20 20 )
SetVar( 0288 1 )
:L0000C8
PerspectiveCall( :L0000D4 )
ShadowCall( :L0000D6 )
Jump( : )
:L0000D4
Perspective
:L0000D6
RefPoint( rel :L000208 0.06 N35:32:14.29 W000:31:46.91
V1= 2000 V2= 40 )
RotatedCall( :L000102 0 0 0 )
Return
:L000102
TransformCall( :L00011A -312 0 0
0 0000 0 0000 0 0000 )
Return
:L00011A
Points( 0
-8 0 -8 ; 0
-8 0 8 ; 1
8 0 8 ; 2
8 0 -8 ; 3
-8 32 -8 ; 4
-8 32 8 ; 5
8 32 8 ; 6
8 32 -8 ; 7
)
SurfaceColor( 05 F0 )
Poly( m 0 0 -32767 8
0 4 7 3
)
Poly( m 0 0 32767 8
2 6 5 1
)
Poly( m -32767 0 0 8
1 5 4 0
)
Poly( m 0 32767 0 32
4 5 6 7
)
Bitmap( gaspump1.r8 0 64 0 107 )
POverride
TexPoly( m 32767 0 0 8
3 0 0 ; 0
7 0 74 ; 1
6 62 74 ; 2
2 62 0 ; 3
)
MonitorTr( :L000208
-20 0 0
2 2 2
0 0 0 )
SetVar( 0284 14 )
:L000208
Return
EndA
; sorted list of objects
; N35:32:14.28 W000:31:46.91 Object # 2
; N35:32:27.18 W000:31:55.66 Object # 1
; ----------------------------------------
; ADF section; ----------------------------------------

; LatRange( N35:29:37.75 N35:34:52.89 )
; ----------------------------------------
NDB( 390.00 90 DAOL NDB_1 N35:32:30.80 W000:31:49.72 0 )
; ----------------------------------------
; Miscellaneous section
; ----------------------------------------

; LatRange( N35:29:37.75 N35:34:52.89 )
; ----------------------------------------
Area16N
Flatten( 112.000 <<<<<<<<<<<change the value in meter <<<<<<<<<<<<<<<<
N35:31:50.69 W000:32:18.46 ; vertex 1
N35:31:46.02 W000:32:16.39 ; vertex 2
N35:31:45.06 W000:32:13.69 ; vertex 3
N35:31:44.41 W000:32:07.79 ; vertex 4
N35:31:45.06 W000:31:44.86 ; vertex 5
N35:31:46.36 W000:31:41.84 ; vertex 6
N35:31:49.08 W000:31:37.85 ; vertex 7
N35:31:51.67 W000:31:32.92 ; vertex 8
N35:31:56.60 W000:31:29.57 ; vertex 9
N35:32:22.13 W000:31:19.62 ; vertex 10
N35:32:23.58 W000:31:19.22 ; vertex 11
N35:32:25.27 W000:31:19.06 ; vertex 12
N35:32:36.09 W000:31:19.06 ; vertex 13
N35:32:38.81 W000:31:19.22 ; vertex 14
N35:32:47.30 W000:31:20.33 ; vertex 15
N35:32:58.12 W000:31:22.25 ; vertex 16
N35:32:59.29 W000:31:22.88 ; vertex 17
N35:33:00.00 W000:31:23.84 ; vertex 18
N35:33:04.00 W000:31:45.34 ; vertex 19
N35:33:04.50 W000:31:49.80 ; vertex 20
N35:33:03.08 W000:31:54.89 ; vertex 21
N35:32:50.51 W000:32:22.45 ; vertex 22
N35:32:41.69 W000:32:42.67 ; vertex 23
N35:32:39.88 W000:32:44.11 ; vertex 24
N35:32:36.83 W000:32:44.42 ; vertex 25
N35:32:32.95 W000:32:43.79 ; vertex 26
N35:32:29.32 W000:32:42.03 ; vertex 27
N35:32:23.62 W000:32:39.17 ; vertex 28
N35:32:15.06 W000:32:33.91 ; vertex 29
N35:32:02.88 W000:32:25.95 ; vertex 30
)
End16

; ----------------------------------------
; AFD Section
; ----------------------------------------
; ----------------------------------------
; Object # 1, offset: 000437, size: 412 bytes
; ----------------------------------------
Container( APT 1 )
APLocation( N35:32:20.70 W000:31:47.70 0 )
ICAO_ID( DAOL )
RwyLoc( N35:32:30.19 W000:31:50.28 0
0 3.50 ; true heading, mag.var.
5904 180 ; length, width
N 36 100 ) ; rwy type, number and surface
RwyLoc( N35:32:29.02 W000:31:56.89 0
75 3.50 ; true heading, mag.var.
5904 197 ; length, width
N 36 2 ) ; rwy type, number and surface
SetupLoc( N35:32:01.68 W000:31:50.28 0
0 1 ; heading, type
N 36 ) ; runway type, number
SetupLoc( N35:32:58.70 W000:31:50.28 0
180 1 ; heading, type
N 18 ) ; runway type, number
SetupLoc( N35:32:21.65 W000:32:30.73 0
75 1 ; heading, type
N 36 ) ; runway type, number
SetupLoc( N35:32:36.40 W000:31:23.05 0
255 1 ; heading, type
N 18 ) ; runway type, number
EndC
; ----------------------------------------
; Object # 2, offset: 0005D3, size: 88 bytes
; ----------------------------------------
Container( NDB 2 )
Navaid( N35:32:30.84 W000:31:49.64 0
0 0.3900 ; heading, frequency
3 3 0; navaid type, class and flags
"DAOL" )
EndC
; Namelists
Namelist( 0409 ) ; language
NameEntry( REGION 0 "Africa" )
NameEntry( COUNTRY 0 "Algeria" )
NameEntry( STATE 0 "France" )
NameEntry( NDB 2 "NDB 1" )
NameEntry( CITY 0 "Tafaraoui" )
NameEntry( AIRPORT 1 "LartigueBAN40" )
EndNL
; ----------------------------------------
; end of SCASM source

put the airfield.sca in the folder where is the SCASM.exe ,drop the airfield.sca file on it ,then you will get a new airfield.bgl
icon23.gif

here there is some advices about the fssc airfield bgl
http://www.sim-outhouse.com/sohforums/showthread.php?20369-Afd

About the gsl Gavinc has did a rework of some cfs2 stock airfields gsl to fit whit the new masks,I don't know how he did it but I suppose that he had used The Martin Whright gsl tool to make the changes.

:wavey:

JP
 
For what it's worth, I found whilst working that the black "0" elevation in the geotiff did more closely match the mesh than the SRTM waterbody images, which seemed too "aggressive". So, if we're looking to use Rhumbas mesh, a raster image of the black selected from each SRTM geotiff might do the job quite well...

This is a good method for coastlines... using the images of actual 0 elevation. Good idea. The only problem is when some coasts extend outward at 0 elevation. SBuilderX lets polys be transparent, so they show over background imagees, so a coast could be quickly checked in that program. I think Sander's Coastline project will allow SBuilderX exports to be used.

I also agree that if GSL was made using faulty placement data, and it's way out of place, then the GSL should be replaced. I also think GSL should be kept fairly sparse... let the missions control the explodable objects and landmarks. :)

Dick
 
Hi all

The only problem is when some coasts extend outward at 0 elevation
and
Anyway, "accurate" is extremely subjective for a historic sim such as this. The SRTM we now use is from the last decade. A lot of the world has changed considerably since the 40's, through global warming, erosion, reclaiming/building (I'm from Holland; a whole province where 1 million people now live was still water in 1945!)
Today the ports are became terminal for passengers contener or oil ,there is some nuclear centrals,many marinas etc...that was built since,the srtm pics integre all these modern extension of the coasts .
It's the reason why I make layer in psp with the Terry Castaneda (for ex) maps and srtm_v2 or gtiff,or any "paper map" I find about the places, to get the final backg. bmp,even if the projection is lightly different ,that give infos about how was the coast in the 40's ,keeping the srtm in priority as guide line for what is common(+90%).
That is good for the hand method ....


JP
 
Jean,

Thanks for the airfield info. I'm ready to dip a toe in, but it's another learning curve ...

Dick,

Getting a little off topic, but I'm wondering how hand-drawing using old maps fits in with Sdc's autocoast tool?

It seems we're after accuracy, but accept that coastlines have changed, but then worry about using the "zero" elevation to automatically map our coastlines?

There's so much to do, we need Sander's automated process to get anywhere...

If we're automating the process, wouldn't zero elevation be acceptable, so long as we can go in afterwards & adjust/ modify for those (smaller) areas that have significant amounts of land <= 0 elevation? (the obvious candidates being areas of holland, for example):kilroy:

Thanks for everyone's help & understanding. I'm sorry if people feel like we're going over old ground, but I'm new to all of this, & I need to understand how we are where we are (now I'm confusing myself :icon_lol:)
 
....
Getting a little off topic, but I'm wondering how hand-drawing using old maps fits in with Sdc's autocoast tool?
.....
There's so much to do, we need Sander's automated process to get anywhere...

when using SBuilder, you can create a new blank project, import the Line/poly info (either SHP, FS9-type BGL, BLN or whatever) for a large area.
You can then either EDIT THIS PROJECT IN SBUILDER to enhance small area's (SBuilder allows you to import multiple background images into a single project), or you can DELETE the lines/poly's if you want to fit it around existing ground2k scenery, then save the project, export as SBX file, run it through cfs2autocoast to generate the cfs2 bgl's.
 
Sander,

Thanks for the clarification - I had the sequence wrong in my head:redface:

No experience of Sbuilder, but it sounds sooooo much more flexible than G2K - can't wait!
 
Sander,

Thanks for the clarification - I had the sequence wrong in my head:redface:

No experience of Sbuilder, but it sounds sooooo much more flexible than G2K - can't wait!

The core of the cfs2autocoast application is that you can feed any type of coordinate line (vector) into it, and it will spit out vtp1/a16n/lwm BGL's. It doesn't matter how big or small the area or how many lines.
When this core is working, basically I can program any interface into it to read various file formats. Right now, I've focussed on SBX files since these are easiest to process and SBuilder can handle so many source file types, and it fits MY personal vision of a conversion method. But if you guys need other data sources converted, or process them differently, or apply data converions along the way, I can easily program interfaces for that. My code is pretty clean and object-oriented so we can be extremely flexible.
 
Salut tous!
, mais c'est une autre courbe d'apprentissage ...
[/ QUOTE]
Si c'est un changement que l'altitude de l'aérodrome, vous verrez, c'est très facile ;)


C'est une bonne méthode pour les côtes ... en utilisant les images des réels 0 élévation. Excellente idée. Le seul problème, c'est quand certaines côtes s'étendent vers l'extérieur à 0 élévation [/ QUOTE]
C'est juste une idée ...... Je me souviens quand j'ai fait mon mailles première fois il ya cinq ans avec la strm_v1 n'est pas corrigé, dans Blackard pour effacer les nombreux bruits de la mer qui ont ces hauteurs à la première version, elle était nécessaire pour définir le niveau de la mer à-3m, qui donnent à calmer les océans et les supprimer également toutes les zones de l'intérieur qui a été à 0m reconnue comme eau et donnez-leur que la terre ....
pourrait-il possible, en utilisant geotiff avec slarti ou autocoast, pour faire des masques de «truquées» prise avec une niveau de la mer défini à-3m puis utilisez-les avec maille normale avec la mer défini à 0M?
Je sais qu'il ne pouvait pas être aussi claire, mais vous pouvez lire sur l'outil Blackart le tuto article complet sur la façon de réparer DEM SRTM peut-être que pourrait donner quelques idées pour résoudre ces zone immergée dans un processus automatisé ....
http://www.terrainmap.com/ lire le "Supprimer les mouchetures SRTM Water Areas " Partie dans le SRTM DEM réparation à l'aide Blackart chapitre de la gauche de l'écran
la langue anglaise est également mieux ......



[QUOTE ].... Je suis désolé si les gens se sentent comme si nous étions déjà-vu, mais je suis nouveau à tout cela, et j'ai besoin de comprendre comment nous en sommes là (maintenant je suis confuse moi-même :icon_lol:) ....[/ QUOTE]

Peu importe! Il existe peu d'expériences sur le sujet sur lesquels nous travaillons, presque tout ce que nous essayons de faire est nouvelle et donne de nombreuses questions sur la façon de progrès à faire cette tâche sur les façons diverses

JP
 
http://www.ptsim.com/index.php?option=com_content&view=category&layout=blog&id=40&Itemid=18
SBuilder for FS2004 to start with.
SBulderX for FSX will possibly be necessery for SHP file conversion, but not right now.

Using SBuilder instead of our old ground2k has the added bonus that your projects can be compiled for fs9 as well, and I'm sure there are a lot of civvie pilots that have retro-fitted their fs9 install to 30's-40's style (Golden Wings) that would appriciate hand-made enhancements.
 
Back
Top