Re: [Flightgear-devel] Center Runway Issue
Ron Jensen wrote: Yes, I understand that. My vision was the flag would be set before genapts is ran. Or are all airports generated at a single pass? For the World Scenery build: Yes as long as 'genapts' doesn't randomly crash at some airfield. Well, in theory we could call 'genapts' once for every individual airfield and feed the parameters on every single call, but this would make things even more difficult if you're just about building a 1x2 degree tile, because this would require you to investigate beforehand which airfields are included in this area. Therefore I still think that having a lookup feature in 'genapts' which is sending each individual airfield's position and gets the corresponding parameters returned from whichever backend (probably via OGR) is the way to go in the long run. We'd just need someone who'd be willing to do the maintenance work on the backend side (this work has to be done anyway, no matter which solution you prefer). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
Hi, John Holden wrote: I'm using a fairly recent version of the CVS on Windows XP - I can't tell you which exactly at the moment, unfortunately - but whenever I land or take off from a center runway, I can't get the center runway texture to display, even though it's in the /Textures folder with all the other runway textures. For example, at KMDW, when you close in on approach for runway 13C, the C does not show, and all you see is the number 13. 13L and 13R appear to work fine. Slightly related is a question I got at the FSweekend. Is FlightGear able to show leading zeros on the runways? Eg. 09, 04 etc. From what I see we do have support for it in our textures (Textures/Runway/pa_0l.png), but generating an airport with runway 09x only gives 9... Cheers, Gijs _ Kakker, Party of Nerd: download ze gratis voor in je Messenger http://buddytest.rulive.nl/default.aspx?src=taglines-- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
On Sat, 2009-11-14 at 09:09 +0100, Gijs de Rooy wrote:
Hi,
John Holden wrote:
I'm using a fairly recent version of the CVS on Windows XP - I can't
tell you which exactly at the
moment, unfortunately - but whenever I land or take off from a
center runway, I can't get the
center runway texture to display, even though it's in the /Textures
folder with all the other runway
textures. For example, at KMDW, when you close in on approach for
runway 13C, the C does not
show, and all you see is the number 13. 13L and 13R appear to
work fine.
Slightly related is a question I got at the FSweekend. Is FlightGear
able to show leading zeros on
the runways? Eg. 09, 04 etc. From what I see we do have support for it
in our textures
(Textures/Runway/pa_0l.png), but generating an airport with runway 09x
only gives 9...
Cheers,
Gijs
It would be a trivial patch to genapts to always generate leading zeros,
however it appears that all US General Aviation airports don't use the
leading zero, US Military bases are mixed, and Europe uses leading
zeros. Looking thru apt.dat it appears all runway numbers have the
leading zero so we can't use that data to algorithmically determine the
format to use... So here's the patch to always generate leading zeros,
but should it be applied everywhere?
diff --git a/src/Airports/GenAirports/rwy_common.cxx
b/src/Airports/GenAirports/rwy_common.cxx
index c5aef04..17a2ff5 100644
--- a/src/Airports/GenAirports/rwy_common.cxx
+++ b/src/Airports/GenAirports/rwy_common.cxx
@@ -52,7 +52,8 @@ void gen_number_block( const TGRunway rwy_info,
if ( num == 11 ) {
sprintf( tex1, 11 );
} else if ( num 10 ) {
- sprintf( tex1, %dc, num );
+ sprintf( tex1, %dl, 0 );
+ sprintf( tex2, %dr, num );
} else {
sprintf( tex1, %dl, num / 10 );
sprintf( tex2, %dr, num - (num / 10 * 10));
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
On Sat, Nov 14, 2009 at 11:53 AM, Ron Jensen wrote:
It would be a trivial patch to genapts to always generate leading zeros,
however it appears that all US General Aviation airports don't use the
leading zero, US Military bases are mixed, and Europe uses leading
zeros. Looking thru apt.dat it appears all runway numbers have the
leading zero so we can't use that data to algorithmically determine the
format to use... So here's the patch to always generate leading zeros,
but should it be applied everywhere?
diff --git a/src/Airports/GenAirports/rwy_common.cxx
b/src/Airports/GenAirports/rwy_common.cxx
index c5aef04..17a2ff5 100644
--- a/src/Airports/GenAirports/rwy_common.cxx
+++ b/src/Airports/GenAirports/rwy_common.cxx
@@ -52,7 +52,8 @@ void gen_number_block( const TGRunway rwy_info,
if ( num == 11 ) {
sprintf( tex1, 11 );
} else if ( num 10 ) {
- sprintf( tex1, %dc, num );
+ sprintf( tex1, %dl, 0 );
+ sprintf( tex2, %dr, num );
} else {
sprintf( tex1, %dl, num / 10 );
sprintf( tex2, %dr, num - (num / 10 * 10));
I suppose we could use some heuristic such as:
4 character airport code that do not start with K or P use a leading
zero, and all other airports omit the leading zero? We could setup the code
logic to be extensible if we find other countries that also tend to omit the
leading zero. That doesn't give us individual control over individual
runways, but it might make things generally better than they are now?
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
On Sat, 2009-11-14 at 12:36 -0600, Curtis Olson wrote:
On Sat, Nov 14, 2009 at 11:53 AM, Ron Jensen wrote:
It would be a trivial patch to genapts to always generate
leading zeros,
however it appears that all US General Aviation airports don't
use the
leading zero, US Military bases are mixed, and Europe uses
leading
zeros. Looking thru apt.dat it appears all runway numbers
have the
leading zero so we can't use that data to algorithmically
determine the
format to use... So here's the patch to always generate
leading zeros,
but should it be applied everywhere?
diff --git a/src/Airports/GenAirports/rwy_common.cxx
b/src/Airports/GenAirports/rwy_common.cxx
index c5aef04..17a2ff5 100644
--- a/src/Airports/GenAirports/rwy_common.cxx
+++ b/src/Airports/GenAirports/rwy_common.cxx
@@ -52,7 +52,8 @@ void gen_number_block( const TGRunway
rwy_info,
if ( num == 11 ) {
sprintf( tex1, 11 );
} else if ( num 10 ) {
- sprintf( tex1, %dc, num );
+ sprintf( tex1, %dl, 0 );
+ sprintf( tex2, %dr, num );
} else {
sprintf( tex1, %dl, num / 10 );
sprintf( tex2, %dr, num - (num / 10 * 10));
I suppose we could use some heuristic such as:
4 character airport code that do not start with K or P use a
leading zero, and all other airports omit the leading zero? We could
setup the code logic to be extensible if we find other countries that
also tend to omit the leading zero. That doesn't give us individual
control over individual runways, but it might make things generally
better than they are now?
Curt.
I commented on the other European-ization thread (about precision
marking differences) that perhaps genapts should take a flag for
European or US style rendering?
Ron
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
On Sat, Nov 14, 2009 at 12:50 PM, Ron Jensen wrote: I commented on the other European-ization thread (about precision marking differences) that perhaps genapts should take a flag for European or US style rendering? Martin pointed out that for the vast portion of airports and scenery areas of the world, they are generated using hands off batch processing methods. This is the primary mode in which genapts and terragear were designed to run. So certainly a flag would be useful if a developer wants individual control over a runway or an airport, but some sort of heuristic for the rest of the airports in the world would also be useful ... or some way to enhance the data file so a per-runway-end decision could be made automatically. I.e. add a field to the database and fill it in with some heuristic, then from there on allow manual tweaking for individual airports. Then the batch processor would have the information it needs for a full world regen, then next time that is run. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
On Sat, 2009-11-14 at 13:01 -0600, Curtis Olson wrote: On Sat, Nov 14, 2009 at 12:50 PM, Ron Jensen wrote: I commented on the other European-ization thread (about precision marking differences) that perhaps genapts should take a flag for European or US style rendering? Martin pointed out that for the vast portion of airports and scenery areas of the world, they are generated using hands off batch processing methods. This is the primary mode in which genapts and terragear were designed to run. So certainly a flag would be useful if a developer wants individual control over a runway or an airport, but some sort of heuristic for the rest of the airports in the world would also be useful ... or some way to enhance the data file so a per-runway-end decision could be made automatically. I.e. add a field to the database and fill it in with some heuristic, then from there on allow manual tweaking for individual airports. Then the batch processor would have the information it needs for a full world regen, then next time that is run. Curt. Yes, I understand that. My vision was the flag would be set before genapts is ran. Or are all airports generated at a single pass? If that's the case perhaps genapts should use the literal runway number from apt.dat, and apt.dat can be edited to replace the leading zero with a space on US GA airports? This should still keep us compatible with x-plane 8.10 datafile specs... Ron -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
Curtis Olson wrote: So certainly a flag would be useful if a developer wants individual control over a runway or an airport, but some sort of heuristic for the rest of the airports in the world would also be useful ... or some way to enhance the data file so a per-runway-end decision could be made automatically. Well, to my understanding we're still trying to keep our data files as close to the v8.10 X-Plane 'standard' as possible. Therefore, if we're still after adding country- or at least continent-specific options to our airfield-generation procedure (genapts), then we should consider having sort of a lookup feature added to 'genapts'. In fact we're in luck since we're having almost all the infrastructure readily at our hands to determine in which country an airfield is situated. So, who's volunteering for setting up (and maintaining!!) a (database) table to map two-letter country codes to the desired/required 'genapts' features ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue
Yes, I understand that. My vision was the flag would be set before
genapts is ran. Or are all airports generated at a single pass? If
that's the case perhaps genapts should use the literal runway number
from apt.dat, and apt.dat can be edited to replace the leading zero with
a space on US GA airports? This should still keep us compatible with
x-plane 8.10 datafile specs...
The problem is one single flag won't be enough. I've been doing some
research... some airports have different precision markings on different
runways at the same airport, so maybe I've opened up a larger bag than I'm
capable of opening here.
However, the code for UK aiming styles should still stand as long as it's
proper:
string texture_name = aim;
if(airport_id.substr(1,2) == EG) { texture_name = aim_uk; }
should, in my mind, change the texture from pc_aim or pa_aim to pc_aim_uk
whenever the airport_id/ICAO code comes up as EG and, therefore, England. As
far as I know, this is the only country which uses a different aiming point.
The problem with the leading 0 is that there are a LOT of small US airports
which have ICAO codes which don't start with the letters K or P. If we could
determine a way to determine what these airfields are, that would be a huge
step in the right direction.
Also, for countries which have single bars as opposed to two- and three-bars, I
see no problem (again, mind my C++ newbishness) with adding something like:
if(airport_id.substr(1,2) == CY /* Canada */ ||
airport_id.substr(1,2) == EG /* England */ ||
airport_id.substr(1,2) == ED /* Germany */ ||
airport_id.substr(1,2) == ET /* Germany (add Australia, Japan) */) {
texture_name = one_a; }
Though you'd have to check to see if you use texture one_a or one_b.
Other than that this is a bigger problem than we can solve in one sitting...
I think eventually going to a database-driven way would work better, but not
until we extricate ourselves from the X-Plane 8.10 airport style, whenever that
is.
Cheers
John
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue - Potential Fix Found
Statto Software wrote: If my simple programming skills don't betray me, I //believe// letter == C; does not actually set letter to equal C, which may be why these airports are being generated without the center runway texture. Your conclusion has been heard: http://mapserver.flightgear.org/git/gitweb.pl?p=terragear-cs Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Center Runway Issue
I'm using a fairly recent version of the CVS on Windows XP - I can't tell you which exactly at the moment, unfortunately - but whenever I land or take off from a center runway, I can't get the center runway texture to display, even though it's in the /Textures folder with all the other runway textures. For example, at KMDW, when you close in on approach for runway 13C, the C does not show, and all you see is the number 13. 13L and 13R appear to work fine. I'm trying to figure out if this is an error on my end, or if there's something in the code which is preventing the C from being displayed? Cheers John -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Center Runway Issue - Potential Fix Found
I think I may have found the problem with the Center Runway texture not
showing, but I'm not at all confident with my C++ skills, so someone will have
to fix TerraGear for me.
However, I've found this code in
/terragear-cs/src/airports/GenAirports/rwy_*.cxx:
int len = rwy_info.rwy_no.length();
string letter = ;
string rev_letter = ;
for ( i = 0; i len; ++i ) {
string tmp = rwy_info.rwy_no.substr(i, 1);
if ( tmp == L ) {
letter = L;
rev_letter = R;
} else if ( tmp == R ) {
letter = R;
rev_letter = L;
} else if ( tmp == C ) {
letter == C; // should this be letter = C;?
rev_letter = C;
}
}
If my simple programming skills don't betray me, I //believe// letter == C;
does not actually set letter to equal C, which may be why these airports are
being generated without the center runway texture.
Cheers
John
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue - Potential Fix Found
2009/11/10 Statto Software stattosoftw...@yahoo.com:
I think I may have found the problem with the Center Runway texture not
showing, but I'm not at all confident with my C++ skills, so someone will
have to fix TerraGear for me.
However, I've found this code in
/terragear-cs/src/airports/GenAirports/rwy_*.cxx:
int len = rwy_info.rwy_no.length();
string letter = ;
string rev_letter = ;
for ( i = 0; i len; ++i ) {
string tmp = rwy_info.rwy_no.substr(i, 1);
if ( tmp == L ) {
letter = L;
rev_letter = R;
} else if ( tmp == R ) {
letter = R;
rev_letter = L;
} else if ( tmp == C ) {
letter == C; // should this be letter = C;?
rev_letter = C;
}
}
If my simple programming skills don't betray me, I //believe// letter == C;
does not actually set letter to equal C, which may be why these airports are
being generated without the center runway texture.
Cheers
John
Hi John,
While I don't have commit rights to cvs, it looks good to me. I guess
there are not many airports with centre runways. :-)
Regards
George
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue - Potential Fix Found
On Mon, 2009-11-09 at 20:28 -0800, Statto Software wrote:
I think I may have found the problem with the Center Runway texture not
showing, but I'm not at all confident with my C++ skills, so someone will
have to fix TerraGear for me.
However, I've found this code in
/terragear-cs/src/airports/GenAirports/rwy_*.cxx:
int len = rwy_info.rwy_no.length();
string letter = ;
string rev_letter = ;
for ( i = 0; i len; ++i ) {
string tmp = rwy_info.rwy_no.substr(i, 1);
if ( tmp == L ) {
letter = L;
rev_letter = R;
} else if ( tmp == R ) {
letter = R;
rev_letter = L;
} else if ( tmp == C ) {
letter == C; // should this be letter = C;?
rev_letter = C;
}
}
If my simple programming skills don't betray me, I //believe// letter == C;
does not actually set letter to equal C, which may be why these airports are
being generated without the center runway texture.
Cheers
John
Looks reasonable to me. Are you actually building these airports? The
attached patch is untested...
Ron
diff --git a/src/Airports/GenAirports/rwy_nonprec.cxx b/src/Airports/GenAirports/rwy_nonprec.cxx
index 93110c6..7fe2d46 100644
--- a/src/Airports/GenAirports/rwy_nonprec.cxx
+++ b/src/Airports/GenAirports/rwy_nonprec.cxx
@@ -245,7 +245,7 @@ void gen_non_precision_rwy( const TGRunway rwy_info,
letter = R;
rev_letter = L;
} else if ( tmp == C ) {
- letter = C;
+ letter == C;
rev_letter = C;
}
}
diff --git a/src/Airports/GenAirports/rwy_prec.cxx b/src/Airports/GenAirports/rwy_prec.cxx
index a7952a0..ce5542e 100644
--- a/src/Airports/GenAirports/rwy_prec.cxx
+++ b/src/Airports/GenAirports/rwy_prec.cxx
@@ -249,7 +249,7 @@ void gen_precision_rwy( const TGRunway rwy_info,
letter = R;
rev_letter = L;
} else if ( tmp == C ) {
- letter = C;
+ letter == C;
rev_letter = C;
}
}
iff --git a/src/Airports/GenAirports/rwy_visual.cxx b/src/Airports/GenAirports/rwy_visual.cxx
index e0f9c9c..32f19eb 100644
--- a/src/Airports/GenAirports/rwy_visual.cxx
+++ b/src/Airports/GenAirports/rwy_visual.cxx
@@ -251,7 +251,7 @@ void gen_visual_rwy( const TGRunway rwy_info,
letter = R;
rev_letter = L;
} else if ( tmp == C ) {
- letter = C;
+ letter == C;
rev_letter = C;
}
}
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue - Potential Fix Found
Looks reasonable to me. Are you actually building these airports? The attached patch is untested... Ron No, I'm not currently in the process of building any airports - though I am generating shapefiles to be used in the default scenery, and Seattle is in the area I'm currently working on (KSEA has a center runway). Though there aren't many center runways it's something I've wanted to see fixed for a long time. Tonight I decided to download the source code and see if I could figure out where the problem was, or at least suggest where I thought it might be. Cheers John -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Center Runway Issue - Potential Fix Found
On Mon, 2009-11-09 at 21:27 -0800, Statto Software wrote: Looks reasonable to me. Are you actually building these airports? The attached patch is untested... Ron No, I'm not currently in the process of building any airports - though I am generating shapefiles to be used in the default scenery, and Seattle is in the area I'm currently working on (KSEA has a center runway). Though there aren't many center runways it's something I've wanted to see fixed for a long time. Tonight I decided to download the source code and see if I could figure out where the problem was, or at least suggest where I thought it might be. Cheers John It might take a few days, but I'll add regeneration of KSEA with my patch to see what happens Ron -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
