Latitude/Longitude Grid Lines... question

#1
Hi, I'm new to ADE, and to the best of my knowledge, I did not see this question already asked in the FAQ:

The latitude and longitude grid lines do not line up with and demarcate full integer minutes (XX.0000), and/or half-minutes (XX.5000) like I would normally expect. Instead, they appear to demarcate number values that are not necessarily round. The lat lines appear to land on the X.25 and X.75 minute lines... while the long lines appear to be very odd-ball numbers you wouldn't expect.

Has anyone else noticed this, and if so is there a way to correct it?

Thank you,

-- John
 
Last edited:

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#2
No you can't change grid lines in ADE. In fact we have considered removing them as a feature. Maybe I am wrong but I do not think they are much used and the same format has existed since the earliest version of ADE. Personally I have never found a use for them :eek:

Perhaps grid lines are important and if so then we should look at them again.
 
#3
No they are not THAT important, but they give a reverence if you rotated the airport and helps quick orintation if you place objecte around the airport.

Still i wouldnt remove, maybe even ad the values of them at the edge of the window, like on maps.
 
#5
No you can't change grid lines in ADE. In fact we have considered removing them as a feature. Maybe I am wrong but I do not think they are much used and the same format has existed since the earliest version of ADE. Personally I have never found a use for them :eek:

Perhaps grid lines are important and if so then we should look at them again.
Hi, and thanks for replying to my thread. Quite clearly, you've had way more experience doing this sort of thing than I do (I've just discovered airport editing in late July), so you're in a much better position to determine what's useful in the program versus what's not.

But I am a little surprised that you think the lines are not useful at all.

As far as I can tell, the lat/long lines are the only things that help reference the airport to the real world as we know it. Without the lines, aren't I just editing blind against a pale-green background?

I'm in the process of trying to add the dry lake bed runways for Edwards Air Force Base in the Southern California Desert (for FS9). I'm using the "Official FAA Airport Diagram" as my guide, for both runway dimensions, headings, and actual latitude/longitude placement of each and every runway.

Unless I'm going about it entirely the wrong way (and if so, please by all means... tell me what's the correct way)... I'm quite literally measuring the lat/long of each runway end-- to the tenth of an arc-minute-- off the Airport Diagram, and then using the gridlines on the program to place the runway nodes to match the latitude and longitude as I read it off the Airport Diagram.

Without the grid lines, I have no idea how this would be possible. I depend on them greatly... and if the lines themselves don't fall exactly on the integer minutes (X.00000)... then I have no idea how one would successfully place runways and make sure they are accurate, relative to the Airport Diagram.

For that reason, yes I think they are vitally important... but maybe because I'm a newbie... I'm overthinking the process and placing too much trust on stuff that isn't important. I'll let you be the judge and advise accordingly.

Again, thank you for your time.

-- John O'Flaherty (Oakland, California, USA)
 
#6
No they are not THAT important, but they give a reverence if you rotated the airport and helps quick orintation if you place objecte around the airport.

Still i wouldnt remove, maybe even ad the values of them at the edge of the window, like on maps.
I agree with the above statement. Valuing them in the windows would make them easier to use as reference lines.

Also, lining them up so that they actually sit atop the...

....[DEG° MIN' .00000] mark for each latitude and longitude marker they represent (instead of being off by + or -0.2657th's of a minute (when I run my cursor over the line), I think would make them more usable.

Just my two-cents. I'm the least experienced guy here. I'm probably the last person that should be suggesting how the developer should run his program... but right off the bat, the grid line anomalies were the first things I noticed.

Because of my lack of experience, I depend on those lines to make sense of the whole process, so maybe that's why I noticed them.... whereas a more experience user knows the program well enough to ignore them, and therefore maybe doesn't care about them as much.

-- John
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#7
The short answer is that you put the airport diagram into ADE as a background image. Some folks use a satellite image and others the airport diagram. In fact you can have both.

It also all depends on just how accurate to the world you want it to be. Some folks want it to be very accurate - however bear in mind that FS itself is not necessarily exact to the world.

Many (including me) subscribe to the view that the airport should be be accurate within its confines and so long as that works it is fine.

Section 8.3 of the English Manual describes working with background images
 
Last edited:
#8
Using grid lines for "accurate" placement is nonsense.

The coordinates of all items in an ADE design can be manually edited to a value if so desired. Nodes can be set to 9 decimal places of a degree or 6 places of a minute in both latitude and longitude.
 
#10
The short answer is that you put the airport diagram into ADE as a background image. Some folks use a satellite image and others the airport diagram. In fact you can have both.

It also all depends on just how accurate to the world you want it to be. Some folks want it to be very accurate - however bear in mind that FS itself is not necessarily exact to the world.

Many (including me) subscribe to the view that the airport should be be accurate within its confines and so long as that works it is fine.

Section 8.3 of the English Manual describes working with background images
Okay... thanks. I had a feeling there was more to it than meets the eye, and that's probably why I should read the manual before tinkering. I'm one of those guys that likes to bust open a new gadget out of the box and start playing around on my own... without reading the directions. Sometimes I get lucky and figure it out... other times I get in way over my head. Sounds like ADE is to be approached with a little more respect than simply taking haphazard guesses.

-- John
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#12
No worries. ADE is a complex tool and reading the manual (at least some bits of it!) is a good idea I think :)
 
#13
Hello:

Regardless of Lat-Lon geographic coordinates "requested" for ex: terrain object placement, FS forcibly "aliases" and renders many object positions to its internal 'multi-LOD' quad matrix 3D world grid (with "corner vertices" and 256 "Area Point" aka 'LOD cell' vertices per quad... that do have known Lat-Lon geographic coordinates). :scratchch

[EDITED]

http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx


Since we are able to make ex: sloped flatten vector polygon BGLs in ADE, IMHO, it might be helpful to also have the ability to display a quad matrix grid at a specified Level Of Detail (aka "LOD") level and 'granularity' of 256 Area Point LOD cell subdivisions per quad / for the terrain mesh that we 'intend' for the airport to be used with in FS by the end user. :idea:

http://en.wikipedia.org/wiki/Granularity

[END_EDIT]


This might be more convenient than having to compile one's vector BGL, then wait to inspect it in FS at run time in order to see how everything 'fits together' with our airport BGL content (since we are unable to open some pertinent "airport-related" XML based BGLs in TMFViewer along with our CVX vector content BGLs). :rolleyes:


IIUC, the vertex positions we "assign" <...or rather 'request' :banghead: > for polygons created in ADE will ultimately be "aliased" to the nearest Area Point for a LOD quad 'cell' at run time in FS, and therefore it is important to specify what terrain mesh internal resolution and/or terrain mesh slider settings should be used with a non-default (aka "not-stock") airport in FS.


IMHO, this is particularly important with custom airports that have complex "sloped flatten" CVX vector polygon BGLs created in ADE by the author. :twocents:


[EDITED]

The granularity of aliasing to Area Points within a LOD quad cell at run time in FS9 will be determined by:

1.) Terrain mesh internal elevation data point grid resolution in meters of the mesh BGL used
2.) Loading of that terrain mesh BGL used into the lowest layers of the FS9 scenery library stack of layers just above "default scenery" areas

NOTE: FS9 loads and displays terrain mesh in "reverse" order compared to other prior and subsequent FS versions

3.) As a function of the terrain mesh slider for complexity in percent
4.) At a terrain mesh resolution vertex density LOD setting allowed by the TERRAIN_MAX_VERTEX_LEVEL (aka "TMVL") parameter in one's active FS9.Cfg.

[END_EDIT]



The granularity of aliasing to Area Points within a LOD quad cell at run time in FSX will be determined (regardless of the terrain mesh internal elevation data point grid resolution in meters of the mesh BGL used) solely as a function of the terrain mesh slider for complexity in percent, and resolution in meters.


Just another idea in favor of greater convenience and accuracy for the ADE user... to minimize "surprises" seen after waiting for one's airport scenery to load up in FS. ;)


Hope these ideas might merit consideration for the "long list" of features to be added in ADE in the future. :)

GaryGB
 
Last edited:
#15
Thanks Jon.

Not wishing to un-necessarily belabor the point (or the very generous programmer), even as a 'non-programmer' I would guess coding for- or actually displaying- that kind of granularity on screen might be about as much fun as having increased granularity added to ones swim trunks in the form of SAND ! :eek:


But, alternatively may I inquire... would it it be feasible to consider implementing a "snap-to-grid" feature for CVX vector polygon content using an 'invisible quad matrix grid' that was selectable by LOD granularity as a function of the FS terrain mesh LOD "intended" for use with one's custom airport made / edited in ADE ? :confused:


Many Thanks again for all the excellent features ADE already offers us, and for perhaps considering something additional to address pre-planning of- or preview of- CVX vector polygon vertex 'aliasing'... as a function of 'intended' FS run time terrain mesh configuration.

[EDITED]

I thought it best to advocate this issue since in addition to the 'hacking out of higher LODs' around 'stock' airports in default terrain mesh by ACES and 3rd party add-on terrain mesh by others (...which will only complicate getting "predictable" results at run time in FS :eek:), we are now seeing an increased use of precision sloped flattens made via ADE by the FS Community, and IMHO we need to see as early as possible in the authoring process exactly where that content will end up relative to the XML airport components. :)

[END_EDIT]


Regards,

GaryGB
 
Last edited:

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#17
I have just noticed that grid lines can become misplaced temporarily when the ADE display is rotated. They definitely are not any use in setting locations or for guideline purposes. It is a bit down the list but we will look at them again. For the moment y'all might be better to turn them off. There is an undocumented feature in ADE 1.50.05. Use the 'G' key to hide or show the grid. This can also be done from the View Menu.
 
Top