Re: [Flightgear-devel] FG-api
Peter Morgan wrote: To add furtheer.. http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh Were all reinventing a wheel.. [...] +YAML++ Yamls is a nice format cos it machine readable.. I don't understand what you're trying to tell us/me. The above script was written four ! years ago, therefore I don't know which wheel has been reinvented, the output is perfectly machine-readable and the motivation is explained in this mailing list posting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17407.html Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG-api
Am 16.06.12 21:39, schrieb Martin Spott: Peter Morgan wrote: To add furtheer.. http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh Were all reinventing a wheel.. [...] +YAML++ Yamls is a nice format cos it machine readable.. I don't understand what you're trying to tell us/me. The above script was written four ! years ago, therefore I don't know which wheel has been reinvented, the output is perfectly machine-readable and the motivation is explained in this mailing list posting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17407.html Cheers, Martin. Hi Martin In this post you write: Note, this directory structure is not meant to be used primarily as a datasource during runtime. Why not? Example: http://code.google.com/p/flightgear-world-scenery/source/browse/data/xplane-single/E/EDDF.xml I don’t know if this make sense, but I kindly ask to check it once and send comments. I would also vote for a less nested structure than A/B/C/D/.xml, just D/.xml (I guess the codes might go to 6 chars soon in xplane apt.dat). Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG-api
Hi Yves, HB-GRAL wrote: In this post you write: Note, this directory structure is not meant to be used primarily as a datasource during runtime. Why not? Because when you look at the runtime performance, parsing XML probably isn't the natural, first choice :-) Example: http://code.google.com/p/flightgear-world-scenery/source/browse/data/xplane-single/E/EDDF.xml I don=92t know if this make sense, but I kindly ask to check it once and = send comments. There was a large thread (during FSweekend 2008, I'd guess) as a follow-up to our announcement of the above XML airport structure. That's way too much to repeat here, better ask the archives. Anyhow, the bigger picture was to use the XML structure as a transport medium and to update relevant changes into local, spatially indexed databases for use with FMS'es and the like. I don't think you want to parse large amounts of XML while dialling through the airport list in your FMS when you quickly have to divert to an alternate because your landing clearance was cancelled and you're short of fuel. I would also vote for a less nested structure than A/B/C/D/.xml, = just D/.xml Well, everybody has his personal favourite for a directory structure. We had been evaluating a lot of pros and cons (poor man's indexing, directory traversal latency, number of directories and the like) before deciding in favour of the structure the way it is now. The mentioned mailing list thread contains a lot of discussion about the directory structure as well and there was no convincing argument against the structure we chose. Therefore I don't think it's clever to push yet another schema unless you can provide a Really Good Reason. Best regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG-api
Am 16.06.12 23:18, schrieb Martin Spott: I don't think you want to parse large amounts of XML while dialling through the airport list in your FMS when you quickly have to divert to an alternate because your landing clearance was cancelled and you're short of fuel. There is no proposal to parse ALL the xml files to get a simple list like you mention i.e. for the FMS. It is going away from parsing the parsed parse parsers anyway. My intention is to get simple and recent xml files that hold any valuable information coming from apt.dat for different purposes, instead of splitting up all the information into small pieces and distribute semi-redundant files and databases which needs to be updated at 3 or 4 places for one single small change. FlightGear scenery history shows that this will probably never happen because it is too complicated this way. I assume also getting this xml data into postgres/postgis tables is much easier than updating and using ogr2ogr plugs (which could be updated of course to the new formats, but I would tend to declare all this stuff deprecated, I don’t see many volunteers to help for such tasks). I would also vote for a less nested structure than A/B/C/D/.xml, = just D/.xml Well, everybody has his personal favourite for a directory structure. We had been evaluating a lot of pros and cons (poor man's indexing, directory traversal latency, number of directories and the like) before deciding in favour of the structure the way it is now. The mentioned mailing list thread contains a lot of discussion about the directory structure as well and there was no convincing argument against the structure we chose. Therefore I don't think it's clever to push yet another schema unless you can provide a Really Good Reason. Best regards, Martin. I didn’t want to discuss directory structure based on personal favourites. The Really Good Reason is to make things easier. And for me personally ... four years old threads are not cut in stone. New ideas arrive, so let’s start a new thread ;-) Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG-api
To add furtheer.. http://mapserver.flightgear.org/git/gitweb.pl?p=sceneryweb;a=blob;f=mapserver/Threshold_ILS_TWR.sh Were all reinventing a wheel.. I think there is a lo of data in blobs, and we converting one blob to another.. Indeed after some reasearch.. robin sppol out the apt table with a last updated which is the last airport in the list.. +YAML++ Yamls is a nice format cos it machine readable.. But to store the values correct eg aa heaging of 200.1999 degrees and alike.. we will need some fefinitions in the guide.. We can then stash the yaml file as the latest.. and everything after that will be updated vias a transmit.. As does the Real world.. the only stuff will be the changes.. which is what we are interested in.. delta.. So its easy from my eyes.. Create a model.. as a core and inherit a sql postgres layer.. and sub quiries as objects.. whether in python, php etc et all.. we need to promote local stuff more.. and create an index based scenario.. pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
