Re: [Flightgear-devel] New experimental mapserver
On Friday 09 September 2011 11:33:17 Curtis Olson wrote: Hi Yves, The general approach that genapts uses this. ... We get to pick the order we process the airport surface objects, so we pick the runways first, and probably the biggest runways before the smaller runways. Then the bigger taxiways before the littler taxiways, etc. Biggest/most important to smallest, least important. ... This is actually incorrect handling. Taxiways should be processed in order they appear in the 8.10 data file. I believe it has been fixed in Terragear-cs to behave this way. A heuristic approach based on size prevents an airport artist from using the taxidraw ordering feature from hinting at the correct orientation. You don't always want the longest taxiway on top. Ron -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Am 09.09.11 22:56, schrieb Frederic Bouvier: I hope you all remember that there is already a 8.50 parser inside fg and code to display airports in the MFD (with Bezier curves). Regards, -Fred Does this parser handle both types, 8.10 and 8.50 format ? As I understand 8.50 is only intermediate and contains a lot of old features without beziers. One problem remains here for me at the moment, to display the beziers or curved polygons on my exeperimental map, I may need an improved apt.dat importer/parser once. I am really impressed about all the work already done in the whole airport and scenery area, the original one in the terragear toolchain, now the work coming up by Peter (and all the work I could not point out here, I am sure I miss some stuff due the lack of my developing experience). Cheers, Yves -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
On Fri, Sep 9, 2011 at 2:49 PM, HB-GRAL wrote: Hi Curt Thank you very much taking time for this. Now this is very interesting, a curved surface with a natural looking slope and correct hills. Can you point me to an example for this ? I guess my current examples like KSFO and EHAM etc. do only provide really flat areas. I did not see any small hills and valleys in FlightGear unless I saw the some artificial shaders from Frederic Bouvier Hi Yves, every airport is an example of this, but maybe hills and valleys is a bad description on my part. What it amounts to is that airports try to be as flat as possible, but even flat areas aren't often as flat as we might first think. Go to any detailed airport chart and look at the runway elevations for the ends of each runway. Another way to think about this is that if you make all the airports completely flat, you will have to deal with cliffs around the edges ... either the airport is sunk down at some parts, and raised up in others relative to the surrounding terrain. Albuquerque, NM is one of the worst offenders I found. You can't fit a flattened airport into the surrounding terrain without the result looking awful. One solution would be to adjust the terrain to blend in with the airport and that would be an ok thing to do. But the problem is that I like to torment myself. Here is approximately what I came up with. 1. Sample the raw terrain elevation across a regular grid that covers the area of the airport. 2. I pick a 3d function that is sufficiently curvy so that it can flex enough to reasonably match the terrain surface, but stiff enough so that it doesn't have all kinds of crazy ups and downs. Then I do a least squares fit of this function to the data. For example, let's say my function is z = a*x^2 + b*y^2 + c*x*y + d*x + e*y + f. Then the least squares fit would pick the best coefficients: a, b, c, d, e, f to fit this function through the sampled terrain data. Very much like a best fit of a line through x, y data except extended to 3d with a bit more complicated function. 3. Now that I have the coefficients for this function, I can use this function to adjust the elevations of everything on the airport surface. The cool thing is that now when you look at an airport built on crazy terrain with maybe a valley falling away between two runways on one side, the edges all around the airport match up reasonably well with the surrounding terrain. I won't say this is perfect in all areas ... some areas have stray data points or noise in the terrain data that confuses things. There's always a chance of a mismatch between airport location terrain location so that we are trying to put the airport on not quite the right underlying terrain. My thoughts for future extensions of this code would be to allow for creating specific tuning parameters for airports that didn't behave well with the default parameters. Hm, indeed, for the moment I was only looking to the two dimensional triangles and saw that genapts (or terragear) is calculating some small areas and probably unnecessary triangles like here at KSFO http://maptest.fgx.ch/screens/wired.png There are also a lot of duplicate items, or it looks like in the wire-frame view, but maybe this items are just very close to each other ... Very likely this is a result of items very close to each other ... especially if the airport designer placed or sized anything visually. One huge problem you run into over and over and over and over again in terragear/genapts work is numerical precision. Things just get weird when you get a gap between polygons that is about the size of one bit difference between two double floating point values. Logically correct polygon manipulation code can blow up due to small numerical problems. And when you throw real world data (and the whole world) at your code, you *will* find every possible way that numerical issues can blow up your code. Anyway, how do you get the natural curved surface without height data Well it's terragear so we have all the processed srtm heigh data already available to just use. ? How are you interpolating between points ? I will try to understand this. Of course, I should not be that lazy and should have a look to the genapts or terragear code instead, right ;-) Once we do the least squares fit of our function, then we can look up a z value for any x, y point within our airport area. Generally I see that I miss some points here with airport generation and it is very different from generating shapes for a map. Hope that helps clarify a bit. Curt -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it
Re: [Flightgear-devel] New experimental mapserver
Curtis Olson wrote: I won't say this is perfect in all areas ... some areas have stray data points or noise in the terrain data that confuses things. There's always a chance of a mismatch between airport location terrain location so that we are trying to put the airport on not quite the right underlying terrain. My thoughts for future extensions of this code would be to allow for creating specific tuning parameters for airports that didn't behave well with the default parameters. An nice example where a high slope leads to bad results would be LFLJ, however, it is possible in such cases to use the --max-slope option in genapts. Chris -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Am 10.09.11 14:47, schrieb Christian Schmitt: Curtis Olson wrote: I won't say this is perfect in all areas ... some areas have stray data points or noise in the terrain data that confuses things. There's always a chance of a mismatch between airport location terrain location so that we are trying to put the airport on not quite the right underlying terrain. My thoughts for future extensions of this code would be to allow for creating specific tuning parameters for airports that didn't behave well with the default parameters. An nice example where a high slope leads to bad results would be LFLJ, however, it is possible in such cases to use the --max-slope option in genapts. Chris After an import of apt.dat for a taxiway area of 10 x 10 degrees I get about 60'000 of areas (or holes) smaller than 1x1 meter. Ok, you can say this is reality by accident, because no artificial surface can be calculated perfectly, and this faults makes it more sexy then everything else. But ... unfortunately, you wont see it at all. Now, cleaning the 2d polygons by grass with common tools like rmarea reduce the imported data about 50 percent. Just for illustration, here is an examples of a (probably) visually edited taxiway with taxidraw: http://maptest.fgx.ch/screens/taxidraw.png I am sure that this very small hole you see here will produce a lot of lag. My personal conclusion here is I really do not fear when we get more points soon emulating curves. When this small areas and holes disappear, we will probably get a lot of resources back. Personally I think we should stop people using taxidraw for taxiway editing, at least for patching lines together to get polygons. Cheers, Yves -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Hi all, If you are looking for airports with extreme runway slope for testing, may I suggest Lukla, Nepal (VNLK). If that one comes out looking right, I'd say you've got the code sorted :) Cheers, Vik On 09/10/2011 02:47 PM, Christian Schmitt wrote: Curtis Olson wrote: I won't say this is perfect in all areas ... some areas have stray data points or noise in the terrain data that confuses things. There's always a chance of a mismatch between airport location terrain location so that we are trying to put the airport on not quite the right underlying terrain. My thoughts for future extensions of this code would be to allow for creating specific tuning parameters for airports that didn't behave well with the default parameters. An nice example where a high slope leads to bad results would be LFLJ, however, it is possible in such cases to use the --max-slope option in genapts. Chris -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Am 10.09.11 21:56, schrieb Viktor Radnai: Hi all, If you are looking for airports with extreme runway slope for testing, may I suggest Lukla, Nepal (VNLK). If that one comes out looking right, I'd say you've got the code sorted :) Cheers, Vik Lukla is just boring ;-) Other suggestions ? Cheers, Yves -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
I was also directed to the ogr2ogr converter. The problem I had with both parsers so far, is the final output is too high level. I need the individual nodes and control points so I can create other useful structures. My initial parser keeps all of the information from the original file. For example, when adding the line data, I want to create polys offset from the contour edges (inside the poly for outer boundary and holes). I also want to offset the lights ( outside of the boundaries and holes). I am also calculating the convex hull for each poly so calculating the airport base, and the airport clearing becomes much easier, as I don't need to worry about the resulting polys becoming complex. This is a lot quicker before converting the curves to line segments. Pete On Fri, Sep 9, 2011 at 4:56 PM, Frederic Bouvier fredfgf...@free.fr wrote: I hope you all remember that there is already a 8.50 parser inside fg and code to display airports in the MFD (with Bezier curves). Regards, -Fred -- I've been using KATL to develop a 8.50 genapt parser for terragear. It has noticeable sloping in the runways (when you get close to the ground with the UFO). I would also like a 'worst case' location to test glPolygonOffset once I get that far. You can see some progress here: http://flightgear.org/forums/viewtopic.php?f=5t=13240 The last post was incorrect, I haven't run into the 64k ushort issue yet - it's just that the poly base that Curt refers to isn't generated correctly for the pavement polys yet. I plan on fixing that this weekend. On Fri, Sep 9, 2011 at 3:49 PM, HB-GRAL flightg...@sablonier.ch wrote: Am 09.09.11 19:33, schrieb Curtis Olson: In addition, there is a fairly sophisticated (and I think cool) step where we fit a natural curved surface across the airport elevation and used the curved surface instead of raw SRTM points. This eliminates the noise in the raw data and gives the airport surface a natural looking slope and correct hills and valleys (in most cases.) Hi Curt Thank you very much taking time for this. Now this is very interesting, a curved surface with a natural looking slope and correct hills. Can you point me to an example for this ? I guess my current examples like KSFO and EHAM etc. do only provide really flat areas. I did not see any small hills and valleys in FlightGear unless I saw the some artificial shaders from Frederic Bouvier Hm, indeed, for the moment I was only looking to the two dimensional triangles and saw that genapts (or terragear) is calculating some small areas and probably unnecessary triangles like here at KSFO http://maptest.fgx.ch/screens/wired.png There are also a lot of duplicate items, or it looks like in the wire-frame view, but maybe this items are just very close to each other ... Anyway, how do you get the natural curved surface without height data ? How are you interpolating between points ? I will try to understand this. Of course, I should not be that lazy and should have a look to the genapts or terragear code instead, right ;-) Generally I see that I miss some points here with airport generation and it is very different from generating shapes for a map. Cheers, Yves -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Flightgear-devel mailing list
Re: [Flightgear-devel] New experimental mapserver
Am 24.08.11 17:51, schrieb Gijs de Rooy: Btw, is the taxiway layer not yet implemented, or is that another broken thing? The taxiways were broken because I first needed a way to handle the current 810 taxiway patchwork shapetry ... http://maptest.fgx.ch/screens/taxidraw.png I converted such taxiway shapes with 300 overlapping polygons and 1200 small holes per airport to one single polygon here, and this is the result now on the map, i.e. EHAM: http://maptest.fgx.ch/screens/eham.png For now I hope that with this cleaning I do not miss some parts, i.e. where the patchwork produced completely invalid geometry, kicked away by grass etc. The ILS centerlines with valid ranges I started to calculate with a new library very useful for such things, just to add as a note: http://geographiclib.sourceforge.net/html/other.html#python Now I wrote some lazy python scripts to take lat/lon/range/heading from our current data to write a postgis sql dump, which gives me a valid table with all the ILS centerlines over the world, as line geometry for the map. An inconvenient way probably, but it works well ;-) Cheers, Yves PS. I am really curious how genapts calculate the taxiway patchworks and how fgfs deal with all this points. I must confess I am too lazy to dive into that. I am looking for an expermental way how I can create airport scenery without this cover-an-area-with-a-number-of-different-lines. Might be ok for runways, but for the airport area/taxiways ... ? Maybe I miss some points. -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Hi Yves, The general approach that genapts uses this. Start with a simple square polygon representing the airport area. As we proceed and add shapes to the airport, they are subtracted from this initial polygon. Also start with an empty polygon representing the airport shapes. As we proceed, objects are added to this polygon. Then we iterate through all the runways and taxiways for the airport. For each 8.10 taxiway we draw the corresponding box. We intersect that box with the accumulated shape polygon, so we can only cover areas that haven't been covered already. Then we add this intersected shape to the airport shape polygon and subtract it from the enclosing polygon. We get to pick the order we process the airport surface objects, so we pick the runways first, and probably the biggest runways before the smaller runways. Then the bigger taxiways before the littler taxiways, etc. Biggest/most important to smallest, least important. In the end we have a jigsaw puzzle of all the individual shapes (so we can texture them properly individually) as well as a master surrounding polygon with holes cut out for all the shapes, plus a master polygon of all the shapes. Then in the end we can cover the whole area perfectly with no overlaps and no seams. In addition, there is a fairly sophisticated (and I think cool) step where we fit a natural curved surface across the airport elevation and used the curved surface instead of raw SRTM points. This eliminates the noise in the raw data and gives the airport surface a natural looking slope and correct hills and valleys (in most cases.) After that we generate all the light points and adjust their height based on the fitted curved surface. I think this approach could be updated for the 8.5 format by just generating different polygon shapes instead of the older collection of rectangles. The down side to the current approach is that it's hard to add markings over the surface. Without getting into all the technical details, if you cut in the markings into the surface structure you end up with an incredibly complex shape with an incredible number of triangles. Bad for load speeds and rendering speeds. If you lay the runway / taxiway markings and skid marks over the top of the base surface, then you have a lot of issues with z-buffer fighting and other odd graphics artifacts. Because our runway surface is curved/sloped we just use a simple draw order trick like other sims might use. But maybe in the past few years people have developed better tricks and techniques for handling this difficult problem of adding complex / arbitrary markings to a surface in a way that looks good mostly edge on (when landing or taxiing) and doesn't blow up your polygon count or encounter z-buffer problems, or require odd hacks of lifting the markings high enough above the runway that you can start to see that they are actually floating and not attached. Regards, Curt. On Fri, Sep 9, 2011 at 7:45 AM, HB-GRAL wrote: Am 24.08.11 17:51, schrieb Gijs de Rooy: Btw, is the taxiway layer not yet implemented, or is that another broken thing? The taxiways were broken because I first needed a way to handle the current 810 taxiway patchwork shapetry ... http://maptest.fgx.ch/screens/taxidraw.png I converted such taxiway shapes with 300 overlapping polygons and 1200 small holes per airport to one single polygon here, and this is the result now on the map, i.e. EHAM: http://maptest.fgx.ch/screens/eham.png For now I hope that with this cleaning I do not miss some parts, i.e. where the patchwork produced completely invalid geometry, kicked away by grass etc. The ILS centerlines with valid ranges I started to calculate with a new library very useful for such things, just to add as a note: http://geographiclib.sourceforge.net/html/other.html#python Now I wrote some lazy python scripts to take lat/lon/range/heading from our current data to write a postgis sql dump, which gives me a valid table with all the ILS centerlines over the world, as line geometry for the map. An inconvenient way probably, but it works well ;-) Cheers, Yves PS. I am really curious how genapts calculate the taxiway patchworks and how fgfs deal with all this points. I must confess I am too lazy to dive into that. I am looking for an expermental way how I can create airport scenery without this cover-an-area-with-a-number-of-different-lines. Might be ok for runways, but for the airport area/taxiways ... ? Maybe I miss some points. -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
Re: [Flightgear-devel] New experimental mapserver
Am 09.09.11 19:33, schrieb Curtis Olson: In addition, there is a fairly sophisticated (and I think cool) step where we fit a natural curved surface across the airport elevation and used the curved surface instead of raw SRTM points. This eliminates the noise in the raw data and gives the airport surface a natural looking slope and correct hills and valleys (in most cases.) Hi Curt Thank you very much taking time for this. Now this is very interesting, a curved surface with a natural looking slope and correct hills. Can you point me to an example for this ? I guess my current examples like KSFO and EHAM etc. do only provide really flat areas. I did not see any small hills and valleys in FlightGear unless I saw the some artificial shaders from Frederic Bouvier Hm, indeed, for the moment I was only looking to the two dimensional triangles and saw that genapts (or terragear) is calculating some small areas and probably unnecessary triangles like here at KSFO http://maptest.fgx.ch/screens/wired.png There are also a lot of duplicate items, or it looks like in the wire-frame view, but maybe this items are just very close to each other ... Anyway, how do you get the natural curved surface without height data ? How are you interpolating between points ? I will try to understand this. Of course, I should not be that lazy and should have a look to the genapts or terragear code instead, right ;-) Generally I see that I miss some points here with airport generation and it is very different from generating shapes for a map. Cheers, Yves -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
I've been using KATL to develop a 8.50 genapt parser for terragear. It has noticeable sloping in the runways (when you get close to the ground with the UFO). I would also like a 'worst case' location to test glPolygonOffset once I get that far. You can see some progress here: http://flightgear.org/forums/viewtopic.php?f=5t=13240 The last post was incorrect, I haven't run into the 64k ushort issue yet - it's just that the poly base that Curt refers to isn't generated correctly for the pavement polys yet. I plan on fixing that this weekend. On Fri, Sep 9, 2011 at 3:49 PM, HB-GRAL flightg...@sablonier.ch wrote: Am 09.09.11 19:33, schrieb Curtis Olson: In addition, there is a fairly sophisticated (and I think cool) step where we fit a natural curved surface across the airport elevation and used the curved surface instead of raw SRTM points. This eliminates the noise in the raw data and gives the airport surface a natural looking slope and correct hills and valleys (in most cases.) Hi Curt Thank you very much taking time for this. Now this is very interesting, a curved surface with a natural looking slope and correct hills. Can you point me to an example for this ? I guess my current examples like KSFO and EHAM etc. do only provide really flat areas. I did not see any small hills and valleys in FlightGear unless I saw the some artificial shaders from Frederic Bouvier Hm, indeed, for the moment I was only looking to the two dimensional triangles and saw that genapts (or terragear) is calculating some small areas and probably unnecessary triangles like here at KSFO http://maptest.fgx.ch/screens/wired.png There are also a lot of duplicate items, or it looks like in the wire-frame view, but maybe this items are just very close to each other ... Anyway, how do you get the natural curved surface without height data ? How are you interpolating between points ? I will try to understand this. Of course, I should not be that lazy and should have a look to the genapts or terragear code instead, right ;-) Generally I see that I miss some points here with airport generation and it is very different from generating shapes for a map. Cheers, Yves -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
I hope you all remember that there is already a 8.50 parser inside fg and code to display airports in the MFD (with Bezier curves). Regards, -Fred - Mail original - I've been using KATL to develop a 8.50 genapt parser for terragear. It has noticeable sloping in the runways (when you get close to the ground with the UFO). I would also like a 'worst case' location to test glPolygonOffset once I get that far. You can see some progress here: http://flightgear.org/forums/viewtopic.php?f=5t=13240 The last post was incorrect, I haven't run into the 64k ushort issue yet - it's just that the poly base that Curt refers to isn't generated correctly for the pavement polys yet. I plan on fixing that this weekend. On Fri, Sep 9, 2011 at 3:49 PM, HB-GRAL flightg...@sablonier.ch wrote: Am 09.09.11 19:33, schrieb Curtis Olson: In addition, there is a fairly sophisticated (and I think cool) step where we fit a natural curved surface across the airport elevation and used the curved surface instead of raw SRTM points. This eliminates the noise in the raw data and gives the airport surface a natural looking slope and correct hills and valleys (in most cases.) Hi Curt Thank you very much taking time for this. Now this is very interesting, a curved surface with a natural looking slope and correct hills. Can you point me to an example for this ? I guess my current examples like KSFO and EHAM etc. do only provide really flat areas. I did not see any small hills and valleys in FlightGear unless I saw the some artificial shaders from Frederic Bouvier Hm, indeed, for the moment I was only looking to the two dimensional triangles and saw that genapts (or terragear) is calculating some small areas and probably unnecessary triangles like here at KSFO http://maptest.fgx.ch/screens/wired.png There are also a lot of duplicate items, or it looks like in the wire-frame view, but maybe this items are just very close to each other ... Anyway, how do you get the natural curved surface without height data ? How are you interpolating between points ? I will try to understand this. Of course, I should not be that lazy and should have a look to the genapts or terragear code instead, right ;-) Generally I see that I miss some points here with airport generation and it is very different from generating shapes for a map. Cheers, Yves -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New experimental mapserver
Hi all I created a new experimental mapnik mapserver. It is based on mapnik/ogcserver/tilecache/postgis/postgres. For testing purposes I pushed 850 aeronautical data from Robin Peel into the database and render some example queries. The database knows the whole world, the example is restricted to a bounding box for testing purposes (8/40/11/44). When all goes fine I can show another experimental example soon with recent FlightGear data, via the official FlightGear mapserver. The code of this project goes free and open source to the FGx repo (while the data of the current example is restricted to non-commercial use). Any comments, suggestions and ideas, contribution welcome ! http://maptest.fgx.ch Cheers, Yves -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Hi Yves, I created a new experimental mapnik mapserver. looks nice! One little thing though, it doesn't work on IE9 (see errors below). Firefox works fine... ;) GijsMozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/5.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; .NET CLR 3.0.30729; AskTB5.6) Wed, 24 Aug 2011 10:24:40 UTC Bericht: Id, tekenreeks of getal wordt verwacht Regel: 60 Teken: 6 Code: 0 URI: http://maptest.fgx.ch/ Bericht: De waarde van de eigenschap init null of niet gedefinieerd en geen functieobject Regel: 244 Teken: 1 Code: 0 URI: http://maptest.fgx.ch/ -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New experimental mapserver
Yves: I guess you are joking sending me localized IE javascript reports ;-) Oops, didn't notice that :P but thanks anyway ! I tried to fix it in the openlayers script, please try again (with IE9). Yeah, works now! Well done! Btw, is the taxiway layer not yet implemented, or is that another broken thing? -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
