All in the Wrong Place

[Charl]

Freeware is based on a selfish premise: what would I create for myself?
You can't force an issue as people will simply drop out.
I've previously been down the road of:
Shall we use the MS default locations for airports, and so keep the whole thing freeware, or
Put them in the correct place, and so lock into either Robin or Christian's payware?
In deciding to provide some AFCADs, GNZLAP locked into the best possible solution available, and so by default rested on 3 payware suppliers:
- HTAI models
- RealNZ
- RBE (then)
There were gripes about that, but frankly, if you don't want my freeware project, that's actually fine by me.
I feel no pressure about not giving myself the best possible NZ flightsim experience (and hence, the users too).
Would I feel "used" by the payware vendors?
No, it's a voluntary decision.
Would I be aggrieved if they promoted their payware through the freeware product?
No, because if they starved I wouldn't get more goodies for NZ.
Is it a problem to have payware vendors involved with a freeware product?
No, they are giving their time, just like you and I.

Long story, but you need to establish this before you take off here.
Consistency will make or break a project like this.

[toprob]

This is pretty clear cut to me. Why would we put any airports at the 'incorrect' position on purpose? Why would that annoy non-payware owners? I hinted to a scenery technique in another thread: With tools like SBuilder and Google kml there is 'no excuse' to put airports in the wrong location in my opinion...

QUOTE

Freeware is based on a selfish premise: what would I create for myself?[/quote]

That's the sane philosophy I have. While I think we should 'aim' to have airports at the correct position, I wouldn't have any objections taking a freeware effort and have it at the wrong position as an intermediate solution, until someone decides to move the airport...

But the end goal of this project surely has to be an as accurate representation of NZ as good as we can do it.

Christian

[greaneyr]

Personally, I don't see how placing an airport in the spatially correct place locks anyone into using a particular mesh. Mesh is mesh isn't it? There should only be one correct mesh at each resolution, since it is derived from real life data. If there is a lot of variation from one mesh developer's product to the next, one of them must be wrong? Also, moving an airport from a default location on a pc where the user has the default mesh won't upset things will it (correct me at any time here since I live in the very flat Manawatu where mesh around airports does nothing)?

On the other hand, neglecting the correct location DOES prevent IFR traffic from making realistic instrument approaches. If an airport has a non-precision approach and is incorrectly placed, the approach chart won't be correct for it. Either the position of the runway will be left or right of where expected, or the DME distance to the threshold will be off, or a combination of the two. I say this because FS default nav aids are perfectly placed. So you end up having a VOR/NDB/DME which is placed perfectly, an approach chart designed for this aid AND the airport, but the airport is in the wrong place. We've also got to consider that Airways are pushing at present to implement GNSS approaches with vertical guidance across the country. While this may not be an issue right now, I expect there to be some payware aircraft addons with such functionality built in within the next year or so, if they aren't already out there. They will most likely use real life data (such as from Navigraph) rather than use that built into FS, so if the runways aren't placed correctly, our scenery won't be compatible with those particular approaches in those particular aircraft.

[toprob]

I'm glad your brought this up, it's been driving me balmy since the project was announced. It is really easy to under-estimate the impact of this.
For instance:

QUOTE (greaneyr @ Jan 20 2008, 09:57 PM) <{POST_SNAPBACK}>

An interesting situation we'll have to decide how to cope with is overriding defaults. For instance, NZPM in FS9 is in completely the wrong place. If we just add to it then we'll have only one AFCAD, but we'll end up with two flatten and exclude areas, as well as the incorrectly placed airport buildings from the default airport. When I've built scenery like this in the past, I've modified the default BGLs, but this isn't an option for distribution as it means distributing copyrighted data. The other time we'll meet this problem is with LWM polygons, such as the enourmous lake north of Ohakea instead of the Rangitikei river. You can't exclude them. Surely there is a way to get rid of them?

As pointed out here, moving an airport into the correct location, without the NZTopo, may mean moving roads, rivers and coastlines. With the topo, the correct location fits right in (except for the flattens) and actually works better in the right place. So the best solution is actually to own the topo:) That's why, if I can't find a solution which covers both the default and the topo, I'll design for the topo.

FS2004 flattens will be a problem, whether or not you use the topo. Modifying default files is never recommended, and FSX actually gives a nice way around this, but with FS2004 we are a bit stuck. I know what issues this can cause -- I released a replacement flatten file with both Auckland and Wellington, and I did one for Laurie, so I know what a pain they can be -- if I had I choice I wouldn't ever do this again. However there is one way around that.
First of all, I'll define the problem:)
Here I'm talking about airport flattens only. FS2004 lumps all flattens in a particular area into one BGL. The area is based on a LOD5 grid -- about 300 kilometres square for each BGL. What I've done in the past is to decompile the default BGL, delete the flatten for the airport I want to change, then recompile it to a new BGL. I then create a separate flatten just for the airport(s) I'm working on. The default flatten BGL is disabled by renaming.
There are a couple of real problems with this. First, if more than one designer is working on the same BGL (which could include dozens of airports) then you'll end up with a mess. Secondly, installation is tricky -- my installer needs to track down the default file to rename it.

However there is one way that this could work effectively -- if there was one NZ-wide project underway to fix all the flattens. This could be done on a LOD5 basis. I dunno how many files are involved -- I'd guess around 20. A messy job, but it may pay off in the end.

Incidentally, I said that FSX is a lot better to work with here -- it has a better topo to start with, so it's just a matter of fixing flattens. FSX introduced a method of excluding existing flattens (and other polygons etc) without changing any default files. Much tidier, as everything can be done from the one scenery folder.

QUOTE (greaneyr @ Jan 21 2008, 02:47 PM) <{POST_SNAPBACK}>

Personally, I don't see how placing an airport in the spatially correct place locks anyone into using a particular mesh. Mesh is mesh isn't it? There should only be one correct mesh at each resolution, since it is derived from real life data. If there is a lot of variation from one mesh developer's product to the next, one of them must be wrong? Also, moving an airport from a default location on a pc where the user has the default mesh won't upset things will it (correct me at any time here since I live in the very flat Manawatu where mesh around airports does nothing)?

The difference between the default mesh and the 20 metre mesh can be dramatic, especially near a river or coast, which a lot of NZ airport are. On the coast, the default mesh may elevate the airport just a metre, or even no elevation, whereas in reality it may be 10 -- 20 metres.

[Timmo]

I dont have experience with FS9 style flattens but for FSX, as Robin noted, the solution doesnt appear hard. It does offer some options though. We could either a) Have one flatten file for each airport (Pros: Easier to manage single airports, Cons: Lots of files) or b) Have one flatten bgl containing all the flattens for the airports (Pros: one file, cons: Harder to manage/disable single airports flattens.

This leads onto how we intend to approach the file system for the airports and scenery. Again, two options as I see them:

a) a separate folder each airport with appropriate scenery and texture subfolders;

Frenzy--

|_Auckland

|_Scenery

..AerialImagery_Auckland.bgl
..LibraryObjects_Auckland.bgl
..RunwayData_Auckland.bgl

|_Texture

..TextureSheet1_Auckland.dds
..TextureSheet2_Auckland.dds

|_Ardmode

|_Scenery

..AerialImagery_Ardmore.bgl
..LibraryObjects_Ardmore.bgl
..RunwayData_Ardmore.bgl

|_Texture

..TextureSheet1_Ardmore.dds
..TextureSheet2_Ardmore.dds

|_etc etc

b) one folder with a scenery subfolder containing all the bgls for all the airports and scenery, and one texture subfolder containing all the agns etc (and photo tiles for FS9 aerial textures)

Frenzy--

|_Scenery

..AerialImagery_Auckland.bgl
..LibraryObjects_Auckland.bgl
..RunwayData_Auckland.bgl
..AerialImagery_Ardmore.bgl
..LibraryObjects_Ardmore.bgl
..RunwayData_Ardmore.bgl

|_Texture

..Texturesheet1_Auckland.dds
..Texturesheet1_Aardmore.dds

etc etc

I certainly prefer option a) as we have to keep the future in mind (i.e. the ease of which users can disable/delete certain airports. The only question I have is can you add a folder and get it to read the subfolders? (i.e. add the Frenzy folder to your scenery list once and then all the data in the many subfolders are added?...does this require changes to the config?)

[toprob]

QUOTE (Timmo @ Jan 21 2008, 05:01 PM) <{POST_SNAPBACK}>

I certainly prefer option a) as we have to keep the future in mind (i.e. the ease of which users can disable/delete certain airports. The only question I have is can you add a folder and get it to read the subfolders? (i.e. add the Frenzy folder to your scenery list once and then all the data in the many subfolders are added?...does this require changes to the config?)

No, both FS2004 and FSX will only recognise a Scenery and a Texture sub-folder within an activated folder. Every separate scenery folder will need to be activated.

Another solution is to divide the country into sections. This is a bit of a compromise between complexity (you end up with a manageable number of folders, each with a manageable number of files) and performance (MS recommend against covering too large a geographical area in one scenery folder.)

One thing which I forgot to say in my earlier post -- it isn't every default flatten which needs to be removed, only the ones which impact upon the landscape negatively. This may include extending out into the sea, or cutting into a hill, or removing important elevation features which define the character of an airport.

[greaneyr]

QUOTE (toprob @ Jan 21 2008, 03:09 PM) <{POST_SNAPBACK}>

The difference between the default mesh and the 20 metre mesh can be dramatic, especially near a river or coast, which a lot of NZ airport are. On the coast, the default mesh may elevate the airport just a metre, or even no elevation, whereas in reality it may be 10 -- 20 metres.

Suppose we think laterally on this for a minute. When people think mesh, they tend to think 'All New Zealand'. Obviously distributing Christian's 20m mesh as free isn't an option, because of licensing restrictions on the data. To replace this data with that acquired from another source would be nigh on impossible, due to the sheer size of the country.

But... if the issue is only with mesh surrounding airports... what's to stop us from getting THAT particular data from another source and releasing it as part of this project for free? I'm aware I could be getting way ahead of myself here since I'm not sure how doable it is to replace small parts of mesh with additional mech, nor how hard it is to acquire and build mesh... But I'd hate for licensing of data that you or I could ultimately go out and get for free just by walking the land with an altimeter or GPS to get in the way of this. I'm not suggesting that's what we do, but I hope my point makes sense.

The data is about our country, which has never been closed source.

[HardCorePawn]

Can we not just do something like this in an install/readme:

Minimum Requirements:

Sim Pilot Experience 75m Freeware Mesh (get it from Geographx)

Recommended Requirements:

Sim Pilot Experience payware 20m Mesh (get it from Sim Pilot Experience)

[Charl]

Nope, 2 different animals, ask those who learned this the hard way...
Actually, we should ask those likely to be making the scenery, hence the poll.

[toprob]

QUOTE (Charl @ Jan 21 2008, 08:27 PM) <{POST_SNAPBACK}>

Nope, 2 different animals, ask those who learned this the hard way...
Actually, we should ask those likely to be making the scenery, hence the poll.

Yes, but given that there'll need to be a compromise, I'd much rather have one fork in the road -- you choose between Christian's 75 metre, or his 20 metre. It may be possible for a designer who has the 20 metre mesh to test in both -- it's a simple matter to move the higher resolution mesh files out temporarily, I do it all the time -- and those who only have the 75 metre can have someone else test. The idea is to devise the best elevation which works for both.

For me, mesh is a lot easier to deal with than the topo. I would never design for FS2004 without the NZ Topo -- it is like shutting one eye and sticking one hand behind your back when you sim -- you are going to be handicapped. Given that one of the goals of this project is realism, you are not going to come near that goal without the NZ Topo installed. What are you going to do, make your own topo? Where are you going to get the data? The Topo scenery is cheap and easy to use. I must admit to thinking that those who are not prepared to purchase the topo scenery are not prepared to improve the realism of FS2004, so they fall outside the scope of a project like this.

As a FS2004 scenery designer, I can certainly see the attraction of FSX...

[Charl]

...which leaads to the next question:
Are there similar issues with FSX?
Or, can one use the default scenery as a basis for long-term scenery design?

[toprob]

QUOTE (Charl @ Jan 21 2008, 09:11 PM) <{POST_SNAPBACK}>

...which leaads to the next question:
Are there similar issues with FSX?
Or, can one use the default scenery as a basis for long-term scenery design?

The FSX default topo is a LOT more accurate -- airport placement is the weak point here, although it is better than FS2004.
With accurate roads (NZ is extra-specially blessed in FSX) it becomes a lot easier to slot the airport boundaries into the correct location. And the coastlines, lakes and rivers are a lot more accurate (including elevations), so you don't get the same problems with a correctly place airport sitting on top of incorrectly (well, not really, it's more an issue of resolution) placed rivers and coastlines.

[Timmo]

from my experience with the 1:50 000 topo data, it's very good and 'trust worthy'. The default FSX vector data is based off this so i see no problems using it.

Mesh: I dont see this being updated (from the 20m payware) for some time as their simply isnt much better out there (I think Terralink has a 15m terrain model but I doubt they will make it avaliable). High resolution replacement mesh for smaller areas will become more common in the years to come as many Regional and Local councils are purchasing Lidar and photogrammetry data. These may lead to some problems, especially with water bodies being at different elevations.

[HardCorePawn]

QUOTE (toprob @ Jan 21 2008, 09:07 PM) <{POST_SNAPBACK}>

Yes, but given that there'll need to be a compromise, I'd much rather have one fork in the road -- you choose between Christian's 75 metre, or his 20 metre. It may be possible for a designer who has the 20 metre mesh to test in both -- it's a simple matter to move the higher resolution mesh files out temporarily, I do it all the time -- and those who only have the 75 metre can have someone else test. The idea is to devise the best elevation which works for both.

I've found its just as easy to switch the TERRAIN_MAX_VERTEX between 19 and 21... to force the sim between the 75 and 20m meshes...