WED-806

I downloaded the recommended version of VIDP from the gateway and validated with WED 1.6.0b1 and there is in fact something wrong:
Several taxiways - some obviously wound counterclockwise, some clockwise - that get all flagged as "wound clockwise". Neither seems to be fixable by the "Reverse function", although the taxiway edge lighing and texture visibility suggests the reverse function as such seems to work right.
So we may have at least one false validation error here, plus likely also a few taxiways that are truely screwed up, but in a previously unseen way, that cannot be fixed by the "reverse" function (high speed exit near south runway east end)

@Julian Former user This XP11 format airport by WEDbot, approved 2-17-17 was likely created in some automated way from OSM data, but has severl significant authoring issues:

• the taxiway edge markings and edge light are present on ALL taxiway edges, resulting in edge markings and lights across the taxiways at all intersections.
• all taxisigns use improper markings (all yellow on black, even runway holds !!)
• runway 11/29 has effectively zero length (both thresholds offset so there is zero useable runway left)
• taxiways used to draw roads out to a mile or more from the airport will definitely kill the road networks for the XP11 global scenery in a very unfavorable way.
• uses no bezier nodes, but rather strange multi-point curves that despite a high node count still look decisively octagonal,

I think this new automatic generation stuff isn't yet ready for primetime ....

@meikelm, can you confirm these problems are not present in the scenery pack's parent (43629)?

The auto-runway-renaming script was not intended to fix any of the types of issues you mentioned if they were present in the previous scenery pack.

Yep - I believe I reported this particular validation issue in WED 1.6 earlier. All Gateway airports are moderated using the latest RELEASE version of WED - 1.5.1r1, and hence this validation issue is not flagged during moderation.

Tyler,
I see, the parent has the same issues, so its not the automatic renaming script's fault. By the way - if that's how we want to address WED-774 Merged to Release , can we assign that to whoever works on this, to avoid duplicate work ? I haven't done much, yet - still figureing the detection of runway hold signs that need changing along with the runway. And not even started with taxi-route renaming, think only the runway tags would need to change.

Julian,
all my mentioned authoring issues appear the same when I load the parent scenery #43629 into WED 1.5.1.
Question is - do we want to validate for

• the extremely offset thresholds, leaving no useable runway ?
• taxiways outside the airport boundary ? (granted, here is airport bdy WED 1.6 does flag this)
  Bit it there were - doing so would prevent taxiways (rather than asphalt polygons) being used to draw stuff outside the airport, which kills all roads in renderfarm.

Re: assigning this to whoever works on WED-774 Merged to Release , I'll mark them as "related" in JIRA, so that whoever takes one will be made aware of the other.

I traced the false validation errors down to these taxiways having self-intersecting segments (illegal as well) being also flagged also by the counter clockwise test. Thus the reversing does not fix things. Usually such self-intersecting paths happen with bezier segments, but here is a case where a purely non-bezier path with really weirdly closed spaced nodes also creates self-intersecting segments.

I think I have a validation for WED-783 Merged to Release , which should also catch this one. Just need to clean up the code and then use it for both issues.

Sorry for not responding until now:

re:

Q. Extremely offset thresholds, leaving no usable runway?
A. Certainly happy to validate for this.

Q. Taxiways outside the airport boundary?
A. I prefer NOT to validate for this - I use taxiways outside of the airport boundary a lot. I know it's not preferred, but currently it's the only way to get plausible looking terrain. The conventional WED terrain polygons are terrible.

@Julian How about we have Alex add polygon definitions that look like apt grass and road asphalt ?
And put the decal overlay statements in the existing terrain .pol definitions, so these polygons actually look exactly as the terrain and not just loke a 1 pixel/100' version of these ?

It would be great to have these .pol definitions - but more importantly we need to be able to define edges of regular .pol with "line" and "light" properties. All too often we need to model service roads that have white edges - and the only way to do this right now is to use taxiways. Adding white lines to the edges of regular asphalt.pol is too tedious!

Jan

+1 for adding the taxiway textures to the .pol definitions. If you try to make any grass, dirt or gravel surface just outside the boundary without taxiways you're having a bad day.

+1000 for adding the high detail decals to the apt_xxx.pol terrain patches to make them match the already existing one that gets placed by the boundary. Everytime you taxi inbetween the two, the texture resolution difference hits you like a A380.

Cheers, Ronny

@meikelm Michael, just to confirm, this isn't actually a validation bug, the underlying pack has piles of self-intersecting lines, right? Or do you want to keep this bug as "self-intersecting lines should not also fail polygon direction"?

I also didn't understand where the grass discussion came from...is that related to the original bug?

The root problem is that this VIDP airport has self-intersecting polygons, which validation does not catch, as we have no test for this now.
Instead the CCW test flags these polygons at validation, which explains why reversing them does not fix it.
IMO the right way to fix is to run a self-intercecting poly test before the CCW wound test and thus flag these polygons with a meaningfull/correct error message.

@bsupnik
Yes, the VIDP validation isssue is self-intersections flagged misleadingly as reverse polygon.

And yes, the grass texture thing is unrelated to WED and this bug. I'll filed it now separateely as XPD-8078 Closed

Its been split up into two separate issues and its being tracked under those numbers.