Hi > > This idea actually _does_ have appeal - hey, I'm right now busy with > > creating an SVG drawing - but I see one drawback here: > > Airport-creators or -maintainers are not _forced_ to think of the > > logical layout. Let's assume some flight simulation does not honour the > > logical layout at all and we'll experience people submitting airports > > without _any_ logic, not even the direction of the taxiway centerline, > > just consisting of the outlines of taxiways and runways. > >Better have just the outlines than having nothing at all. People more >experienced in airport layout could take over and add the missing parts. >Welcome to the power of open source. I for myself would volunteer for this >since I don't like redrawing runway borders from an aerial. Its all about >collaboration :-) > it's not just layout that is important, there have been instances where people have wanted uni-directional runways... this could just as equally apply to taxiways (I haven't come across any examples of this YET!)... defining taxi-ways as unirdirection or bidirectional could cater for specifically styled runway signs (if indeed this was the case in RL)... taking it a step further... apron markings could be layered over this. With the proprietry APT format this would be hard to implement...a more generic "tree" structure would be more extensible (I think this has been mentioned before as an advantage)
> > In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an > > airport description language that consists of nothing but the logical > > layout at least for those objects, that relate to the core airport > > operations (runway, taxiway, apron, tower location), forcing the user > > to create a logical sense behind _every_ object. > >This is exactly what I have in mind. It just contains 'embedded' svg >descriptions of the physical layout of the parts that make up the logical >model. Something like this > ><fg:runway id="03L" > > <fg:runwaypart material="concrete"> > <svg:polygon .... > </fg:runwaypart> > <fg:runwaypart material="asphalt"> > <svg:polygon ... > </fg:runwaypart> ></fg:runway> > >(NOTE I dont know svg syntax :-)) > >Of course this also means that only an svg editor is not enough to fully >specify an airport. > Just as a text editor will edit a dat file... TaxiDraw does a much better job because it enforces a set of rules. > > Yes, I feel that this > > path might be a bit steep in the beginning but I believe it's the only > > one that saves us from major trouble once we expect every airfield to > > contain a certain amount of logic and realizing that noting's there. > > Opinions ? > >I think this is a quality control issue. So it should be solved in the >process >rather than in the data format. > Agreed, the tool enforces the quality control and the data format stores that information such that the result of the rules is also stored for other editing sessions. > > I must admit that from reading some explanations on the 8.50 format I > > still didn't understand which route this new format is heading for - I > > simply failed to find the logic in the description .... > >ASFIU they only want to provide the high-level description and leave >everything else to the sim. That makes it easy for airport modellers since >there are less options but I can see issues arising regarding flexibility. >Example case: I've seen taxi lights standing besides the asphalt and on the >other hand others buried within the taxiway concrete. Just specifying that >there is taxiway lighting is not enough in my opinion. > >Thomas :-D ene _________________________________________________________________ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
