Re: [Flightgear-devel] Openstreetmap vs. G**gl
I don't know the specific answer in this case, but it does illustrate one of the surpreme challenges in mixing different gis databases ... you end up with information from different sources, adhering to different standards, appropriate for different scales, using different datums, different surveying techniques etc. Sometimes manually processed or manually entered/created, processed in different ways, etc. etc. Asking a cartographer "where is it?" is just about as difficult a question as asking an astronomer "what time is it?" Curt. On Sat, Sep 10, 2011 at 5:54 PM, HB-GRAL wrote: > Hi all > > Unfortunately I just run into another problem with my map. > > This is what I see on my currently generated map using 8.10 taxiway data > and 8.50 runway data (this is no reference and a crude mixup of course, > I apologize in adnvance): > http://maptest.fgx.ch/screens/mapping.png > > But now, I discovered something really strange. I was looking to > different maps while exploring this area with FLightGear. > > This is what I see in with recent terrasynced scenery: > http://maptest.fgx.ch/screens/flightgear.png > > This is the same position on mpmap02 server: > http://maptest.fgx.ch/screens/google.png > > This is exactly the same position on OSM: > http://maptest.fgx.ch/screens/openstreetmap.png > > I am just curious why FlightGear and OSM have the same "accurate" > position, and Google map shows another one. > > I am sure, there are different problems, but some enlightenment will be > greatly appreciated here. > > Beside of that, where does this inexisting taxiway to the left come from > ? Is this a FlightGear feature ? Something like > "we-have-no-taxiways-so-there-is-probably-one-to-the-left" ? > > 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 > -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Openstreetmap vs. G**gl
HB-GRAL wrote: > I am just curious why FlightGear and OSM have the same "accurate" > position, and Google map shows another one. I might not have entirely understood your question (it's late and I'm tired), but one cause to be considered could be that OSM folks might simply have imported from the good old NIMA airport database - the same source which has built the basis of the X-Plane aiport collection. > Beside of that, where does this inexisting taxiway to the left come from > ? Is this a FlightGear feature ? Something like > "we-have-no-taxiways-so-there-is-probably-one-to-the-left" ? Exactly, that's a default in Robin's collection. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Openstreetmap vs. G**gl
Google maps are notoriously incorrect on co-ordinates. Even their own road map overlay does not align perfectly with the scenery. You can check the accuracy yourself if you have a GPS receiver and visit a set of easily identifiable points like road junctions. My understanding is that they stitch their photos together and then produce tiles. These tiles are fitted to a spheroid using an array of reference points. Any position that you try to measure that is not close to one of these reference points will have an interpolation error. The photography and stitching process is bound to introduce a degree of distortion. Point positions of aeronautical navaids and airfields have mostly been well surveyed and their positions should therefore be accurate. Alan -Original Message- From: Martin Spott Sent: Sunday, September 11, 2011 11:39 PM Newsgroups: list.flightgear-devel To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Openstreetmap vs. G**gl HB-GRAL wrote: > I am just curious why FlightGear and OSM have the same "accurate" > position, and Google map shows another one. I might not have entirely understood your question (it's late and I'm tired), but one cause to be considered could be that OSM folks might simply have imported from the good old NIMA airport database - the same source which has built the basis of the X-Plane aiport collection. > Beside of that, where does this inexisting taxiway to the left come from > ? Is this a FlightGear feature ? Something like > "we-have-no-taxiways-so-there-is-probably-one-to-the-left" ? Exactly, that's a default in Robin's collection. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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 -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
Am 11.09.11 03:20, schrieb Curtis Olson: > > Asking a cartographer "where is it?" is just about as difficult a question > as asking an astronomer "what time is it?" > > Curt. Hi Curt These are very good questions. I will ask some cartographers and astronomers. Cheers, Yves -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
Am 12.09.11 00:39, schrieb Martin Spott: > HB-GRAL wrote: > > Exactly, that's a default in Robin's collection. > Hi Martin Yes, sorry, you answered me this one some months before and I just forgot about. It is part of the collection and this probably makes sense. Cheers, Yves -- 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] Openstreetmap vs. G**gl
Am 12.09.11 09:56, schrieb Alan Teeder: > Google maps are notoriously incorrect on co-ordinates. Even their own road > map overlay does not align perfectly with the scenery. You can check the > accuracy yourself if you have a GPS receiver and visit a set of easily > identifiable points like road junctions. Hi Alan I see now also some differences between OSM and "our" apt.dat and the title of this post is probably wrong (as many other details sometimes coming out here from the university of half-knowledge). Some of the airports and runways fit exactly on all the maps. Maybe "edited" airports ? I dont know, it is very difficult to verify for me, maybe I am on some bad and exotic examples only. (I was thinking about what happens with "wrong" runway coords from apt.dat, i.e. when this data is processed via shapes with recent landcover and height data for FlightGear scenery, coming from other resources. But I confess this gives me to much smoke over my head, also without taking slopes and hills into account). > > Point positions of aeronautical navaids and airfields have mostly been well > surveyed and their positions should therefore be accurate. > Yes, I think (or hope) so ;-) Also here, I only see differences between apt.dat and other geodata. We use X-Plane data, OSM uses another aeronautical database with more than 4 airports recently in public domain (ourairports.com). I dont know if this is based on the older but unfortunately disappeared DAFIF resources too, but anyway it looks like it is also an interesting collection and has a "living" updater community. I just discovered this one, I will do some private examples with this data. And be quiet for the rest of the year, or at least for some days. Cheers, Yves -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
HB-GRAL wrote: > I see now also some differences between OSM and "our" apt.dat [...] Note that OSM might be aiming at a different target, they're not necessarily building a database which meets the specific requirements in (simulated) aviation. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
Am 15.09.11 18:12, schrieb Martin Spott: > HB-GRAL wrote: > >> I see now also some differences between OSM and "our" apt.dat [...] > > Note that OSM might be aiming at a different target, they're not > necessarily building a database which meets the specific requirements > in (simulated) aviation. > > Cheers, > Martin. Hi Martin No, it looks like the mapping with apt.dat data is inaccurate, at least outside the United States. I checked some airports the last days. You can not say that FlightGear or X-Plane data is accurate and the rest of the mapping world is missing the "points". It does not depend on aviation or not. A lot of runways are misplaced, and I am just asking about the reason. Maybe one of the reasons is that apt.dat is based on old analog imagery, not available anymore. Cheers, Yves -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
On 09/15/2011 03:08 PM, HB-GRAL wrote: > No, it looks like the mapping with apt.dat data is inaccurate, at least > outside the United States. The following repeats an email I sent quite a while ago, which somehow seems to have gotten lost: On 09/10/2011 03:54 PM, HB-GRAL wrote: > I am just curious why FlightGear and OSM have the same "accurate" > position, and Google map shows another one. > > I am sure, there are different problems, but some enlightenment will be > greatly appreciated here. Many of the entries in apt.dat are wrong. Large errors are particularly prevalent in the entries for small airports that don't have instrument approaches. In some cases google maps makes the same mistakes. I haven't checked whether openstreetmap makes the same mistakes. If so, the obvious explanation is that all three have copied from each other, or from the same defective upstream source. When I say entries in apt.dat are wrong, I am not comparing against one database of features against another, but rather comparing it against satellite photography and shuttle radar terrain mapping ... which are known to be quite accurate. Indeed the accuracy of the imaging is confirmed by the fact that *some* of the apt.dat entries are spot-on, especially for the major airports. On 09/12/2011 12:56 AM, Alan Teeder wrote: >> Point positions of aeronautical navaids and airfields have mostly been well >> surveyed and their positions should therefore be accurate. Well, maybe they "should" be accurate, but in fact many of the entries in apt.dat are not. Some of the errors are quite large. For example, the location of CO80 "USAF ACADEMY BULLSEYE AUX AIRSTRIP" is off by several hundred meters. As another example, the runway heading for 57AZ "La Cholla Airpark" is wrong by more that 20 degrees. Furthermore, the location and runway heading are wrong for 2B3 "PARLIN FLD". If you want a more-or-less endless supply of errors, look at even smaller, private, and/or unpaved airfields. The database also contains a goodly number of entries for airports that ceased to exist many years ago. These errors have got nothing to do with metaphysical questions about the meaning of "where it is". The entries are just wrong. They've been wrong all along. In most cases version 850 has the same errors as version 810. The metaphysical issues are much, much smaller. As it says at ftp://itrf.ensg.ign.fr/pub/itrf/WGS84.TXT >>> In general the ITRS (and its realizations ITRFyy) are identical >>> to WGS84 at one meter level. Similarly, there are still some people who still use NAD83, which is not unreasonable. It agrees with WGS84 within one or two meters in North America ... and the offsets are well known. The apt.dat errors are hge compared to any such offsets. = I have a tool that reads apt.dat and writes kml. Thereupon the kml can be imported into a GIS system such as GRASS or google-earth. This making it easy to compare apt.dat with the satellite and shuttle images. -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
On Thursday 15 September 2011 22:08, HB-GRAL wrote: > No, it looks like the mapping with apt.dat data is inaccurate, at least > outside the United States. > > I checked some airports the last days. You can not say that FlightGear > or X-Plane data is accurate and the rest of the mapping world is > missing the "points". It does not depend on aviation or not. A lot of > runways are misplaced, and I am just asking about the reason. Maybe one > of the reasons is that apt.dat is based on old analog imagery, not > available anymore. I like to think that the positional errors of many (most non US?) aerodromes are due to mistakes made when changing from one datum to another. Errors in runway orientation at unmodifed airfields (with default layouts) appear to be caused by confusion between magnetic and true bearings, with magnetic being used as true. Not a major problem where magnetic variation is low but an error nonetheless. Martin. -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
On 09/15/2011 05:15 PM, Martin Fenelon wrote: > I like to think that the positional errors of many (most non US?) > aerodromes are due to mistakes made when changing from one datum to > another. Well, that's not what I think, based on looking at the data. The very first non-US example I looked at was ES03 "Hova" for which the apt.dat position is off by hundreds of meters, to the southeast. Nearby we have ESVF "Frolunda" for which the apt.dat location is off in another direction, and the relationship of its two runways to each other is wrong. It is hard to see how a change in datum could have a different effect on two nearby airports ... and there is just no way it could have a different effect on two runways at the same airport. There aren't that many different datums to play with. > Errors in runway orientation at unmodifed airfields (with > default layouts) appear to be caused by confusion between magnetic and > true bearings, with magnetic being used as true. Uhh, in apt.dat the runway heading for ES03 is off by more than 35 degrees. The local magnetic deviation is more like 4 degrees. Bottom line: Many of the apt.dat entries are just wrong. You don't need any ultra-sophisticated geodetic expertise to understand what is going on. The entries are just wrong. If you want something to be accurate to a few centimeters, or even a few meters, then some expertise is required, but that's not what we're talking about here. -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
Right -- outside the USA, much of the x-plane airport data is hand entered and submitted by end-users with no quality control other than people are welcome to research and fix problems they find as they find them. I wouldn't be surprised if some of the entries are complete guesses or crazy typos. Inside the USA we have the FAA data to reference. For a while DAFIF was world wide, but more recently I think they pulled that back and just maintain the USA data. Quality + free GIS data is often hard to find. We are very lucky to have some of the products we do have ... like SRTM and VMAP. Curt. On Thu, Sep 15, 2011 at 8:42 PM, John Denker wrote: > On 09/15/2011 05:15 PM, Martin Fenelon wrote: > > > I like to think that the positional errors of many (most non US?) > > aerodromes are due to mistakes made when changing from one datum to > > another. > > Well, that's not what I think, based on looking at > the data. > > The very first non-US example I looked at was > ES03 "Hova" > > for which the apt.dat position is off by hundreds of meters, > to the southeast. Nearby we have > ESVF "Frolunda" > > for which the apt.dat location is off in another direction, > and the relationship of its two runways to each other is > wrong. > > It is hard to see how a change in datum could have a different > effect on two nearby airports ... and there is just no way it > could have a different effect on two runways at the same airport. > There aren't that many different datums to play with. > > > Errors in runway orientation at unmodifed airfields (with > > default layouts) appear to be caused by confusion between magnetic and > > true bearings, with magnetic being used as true. > > Uhh, in apt.dat the runway heading for ES03 is off by more > than 35 degrees. The local magnetic deviation is more like > 4 degrees. > > Bottom line: Many of the apt.dat entries are just wrong. > > You don't need any ultra-sophisticated geodetic expertise > to understand what is going on. The entries are just > wrong. > > If you want something to be accurate to a few centimeters, > or even a few meters, then some expertise is required, but > that's not what we're talking about here. > > > -- > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
HB-GRAL wrote: > I checked some airports the last days. You can not say that FlightGear > or X-Plane data is accurate and the rest of the mapping world is missing > the "points". Sure, DAFIF (which is the source to most of 'our' runways) is neither error-free nor complete. That's why corrections are being applied to 'apt.dat' all the time. Anyhow I'd warn against taking too drastic measures by discrediting these thousands of aeronautically precise pairings of runways, ILS'es, DME's and the like which are part of 'apt./nav.dat' just because you've probably found a few dozend of inaccurate runways. I'd happily be convinced that there's something better than Robin's collection, but I'm convinced that people are likely fooling themselves (and others) by under-estimating the effort to build a database which would serve as a suitable as a replacement. Folks, if you really have something better, show it to us. Show where it is, show that the license or terms of use allow us to create Scenery from it to ship with FlightGear, demonstrate that it's at least as accurate as our 'apt./nav.dat' are and demonstrate how to make practical use of it. Keep in mind that just counting the number of airports listed in the collection still doesn't make a functional ILS approach. Until then, everybody is invited to improve our current collection ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
