• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSX earth curvation and ground polygons

Hi Paul,

BASys said:
AIUI, that is not the case,
(from reading Adam's doc).
Click to expand...

I assume you mean the paper Adam wrote about the terrain system? I have been using that for my reference as well and will take another look at it.

BASys said:
Are you saying -
- The total size of any cluster does not exceed 100m ?
Or -
- Your individual polygons don't exceed 100m,
but the cluster does ?
Click to expand...

In the scenery every polygon is broken down to triangles of course. So what I am saying is that if you make sure the edges of those triangles are not longer than 100 meter it seems to work fine. The polygons then follow the curve of the earth correctly.

BASys said:
1 metre is still 1 metre. :)

It's just your large flat object that's been reprojected,
so no longer meets your expectations. :D
Click to expand...

That's not always true. E.g. one meter in Dutch RD projection is not the same as one meter in the flat earth projection used by FS. Same applies to one meter in UTM. But that is only an issue when using existing data as input into your deisgn and that is not the case now.

BASys said:
Are your 100m polys -
- still flat planes ?
- round-earth projected, (i.e. domed) ?
Click to expand...

They are flat planes. But under that size the scenery engine should compensate.
 
Hi Folks

Arno -
arno said:
I assume you mean the paper Adam wrote about the terrain system?
Click to expand...
I'd been referencing both Adam's paper,
and also his suggested HowTo recipe.



arno said:
That's not always true.
E.g.
one meter in Dutch RD projection
is not the same as one meter in the flat earth projection used by FS.

Same applies to one meter in UTM.
Click to expand...
1m is still 1m.

It's the coords and projections that are different.
e.g.
For same coords
in WGS84 v OSGB36
location could be 300m displaced.



Importing != Reprojecting. :D



All projections are based on an origin datum.

WGS84 is earth mass-centered.



RD, (link will mean more to you than me). :D
AIUI form a brief google -
Is based on Amersfoort as the datum.

Depends on your data source -
If ETRS89 based, expect ~ 50cm longitudinal displacement from WGS84. :D

Seemingly some NL mapping, e.g. Dutch Hydrographic Office,
is based on the Bessel 1841 reference ellipsoid,
Bessel r/e axes are about 700 m shorter
than that of the mean Earth ellipsoid derived by satellites.



UTM is a cylindrical projection and stretches distances east-west.

UTM has 60 locale origins, (meridians),
and is further divided by latitude bands.

Requires application of correct origin.

The scale is only true on the central meridian.

The remoter your coords are from that origin
the more displaced they will be, (the longer "your 1m" will be).



Bottom line,
unless correct transformation is applied,
coords and scale will always be off.

Be aware also,
from a quick google,
not all converters contain correct transformation data.



HTH
ATB
Paul
 
Last edited:
Hi Paul,

Of course you are right. But the point I tried to make is that you can not for example measure a runway in a drawing that uses the Dutch RD projection and then just use that length to draw it in FS. That will not necessary line up, I have seen that mistake before. So from that point of view the meters are not "the same".
 
Hi Folks

Arno -
Understood. :D
Apologies for the lecture, (someone might find it useful).

I had similar issues with "lifting" coords
when placing platforms
in the early stages of our ODG Project.

HTH
ATB
Paul
 
I hate to break up an intelligent conversation with a question from a simpleton, but what ill-effects can one expect to see if the 100m rule isn't adhered to?

I ask because I've found that breaking polys up into 1000ft chunks works just fine. My polys don't float, and the aircraft doesn't sink into them at any point. I also see no evidence of flickering or any other issue associated with the round-Earth problem.

The only anomoly I see is the fact that I have to account for increasing dimensional errors as verts move away from the origin. If this is purely an issue of "reprojection" and using a different datum for designing than FSX uses for rendering, then it would appear to me that the 100m limitation is unncessary.

Regards,

Nick
 
Hi Folks

Nick -
Apologies for my re-projection diversion,
it's only relevant to sourcing of data.

Apart from a potentially increased FPS impact,
displayed affected issues will depend on the user's slider settings.

Higher slider settings
will display more apparent displacement.

Apparent vertical displacement,
and ground-sinking of wheels,
will vary with user's viewpoint
relative to poly's origin.

HTH
ATB
Paul
 
Hey Paul,

Good point. My terrain/texture sliders are maxed, and I see no issues regardless of viewpoint or distance. Things look solid whether overhead at 30,000ft, on a 3 mile approach, or taxiing around the ramp.

I wonder if lower sliders would reveal issues that I have not seen on my system. I'll certainly have to check that out.

I'm still not clear on how I would go about correcting for differing projections between source material and FSX. But I'll save that question for another thread...I don't want to derail your conversation.

Perhaps more germane to the topic though, here's a sample of the difference that I see between FSX and Max 8 that might shed some light on the magnitude and nature of the positional/dimensional errors.

My scene origin is at the threshold of runway 24. In real life, the runway is surveyed as 10,900ft in length. In order to make my poly conform to the geo-rectified ortho-imagery, I must make my runway 10,910ft long in Max 8.

On the other hand, an examination of the xml-based "ADE" runway reveals its length to be 10,983ft. This runway is the FSX default runway, and without any modification, it matches the new ortho-imagery perfectly with respect to position and dimension.

What does one make from that set of data?

Nick
 
Hi Folks

Nick -
Your scaling factor will depend on your target location
and your source data's displacement from its origin.



Not seeing any "attached samples" here.



You say you see no issues,
but your PP mentions displaced verts.



Where did you obtain this geo-rectified ortho-imagery ?

Guessing you'd made your ADE
to match an in-game displayed photo-scenery.

Sounds like you've overstretched your rwy.

ADE should match IRL rwy length.



HTH
ATB
Paul
 
Hi Paul,

Yeah, sorry I can't post pics yet.

My source data for dimensions is a CAD drawing limited to the bounds of the airport. The drawing is explicitly dimensioned, and depicts taxiway widths, runway lengths, filet radii, etc... It makes no mention of a specific projection or datum used in it's creation.

The 6inch resolution orthoimagery was obtained from the state GIS office, and contains the required metadata for use in Resample. The Resampled imagery matches the existing FSX vector data without error or distortion.

The existing default (unedited) runways match the ortho imagery EXACTLY. Though, when I view the default runways in ADE, the stated length is 7 feet shorter than the surveyed length.

In order to make my Max 8 ground polys match both the imagery and the default runways, I have to draw a runway that is 10 feet longer than the "real world" dimension, and 17 feet longer than the ADE runway.

My comment about seeing no issues was intended to discuss the fact that I observe no sinking/floating/flashing issues commonly associated with the Round-Earth issue when dealing with polygons tasselated at 1000ft intervals instead of the widely publicized 100m.

Are you thinking that the scaling issues I'm seeing would be mitigated by 100m tasselation? It sounds like Arno is seeing similar displacement errors despite greater tasselation, no?
 
Hi Nick,

The 100 meter has been mentioned by the MS developers as a good distance between vertices to get no trouble with the curve. But they never said it was a hard border, so maybe some bigger value also works.

If the vertices are 500 meter apart, the height difference due to the curve is only about 2 cm. So I can image that with your 300 meter (1000 ft) it might still work quite OK.

I think the displacement you are seeing can be related to two issues:

  1. The way MS is putting these flat polygons on the shape of the earth. I believe this is also why I see gaps between my polygons. Looks like the same issue to me.
  2. It could also be the data you used. When I made the Amsterdam Schiphol airport years ago and just used the data from the drawing I got everything was out of place. This was because the RD projection used there can not be put into FS directly. Some rotating and scaling was needed to match the FS coordinate system exactly. But as you mentioned before, in this thread we are focussing on item 1 now :).
 
You must log in or register to reply here.
Back
Top