Closed brisbori closed 9 years ago
alistairmgreen
commented
9 years ago Sorry if the above comments sound like nit-picking!
I am grateful for the bug fix as I wasn't aware of the problem with EW loggers putting in a blank declaration.
I do think that the map looks clearer now that the take-off and landing points are no longer shown as part of the task.
Thanks for your help.
brisbori
commented
9 years ago On 01/09/15 21:42, Alistair Green wrote:
Sorry if the above comments sound like nit-picking!
I am grateful for the bug fix as I wasn't aware of the problem with EW loggers putting in a blank declaration.
I do think that the map looks clearer now that the take-off and landing points are no longer shown as part of the task.
Thanks for your help.
— Reply to this email directly or view it on GitHub https://github.com/alistairmgreen/jsigc/pull/11#issuecomment-136855229.
Comments on the comments:
I hadn't really thought about the "declare goal" situation. In fact it's not relevant to Silver Distance- if you do 50 Km (extended by the 1% height loss rule) you don't need a declaration. However there are situations (eg: goal speed records) where the flight is simply A to B (although rarely done). In that case you'd still have "00" as the last two digits of the first "C" record. Bearing that in mind the only way I can think of to trap the situation we get with the EW would be by looking at the second "C" record and assume no-one has a start point at the equator. Just taking four as the minimum number still won't work as all four can still be empty. I think we can accept there is no such thing as a declaration without a start point.
I take your point about losing the takeoff and landing at the "parse igc" stage. The only reason for doing it as I did is I wanted to keep the takeoff and landing points in cases where they are declared for the text display of the declaration- they are still of interest and someone obviously wanted to enter them. In other words, we want them for the text but not the plot, and I couldn't think of an elegant way of doing that without the complication of extending the IgcFile object.. Any thoughts? There are a couple of ways I can think of generating the array we want for the plot, and having seperate IgcFile.start and IgcFile.Finish objects.
I hadn't really thought too much about the "==" and "===" issue. The same thing applies in php, but I've usually not bothered as long as I'm confident we have the same type on both sides. I can change the style in future.
Commenting out was done for clarity at that point, I expected it to get deleted at some point. I'll bear your comments in mind.
More thoughts- having just got your e-mail since I started writing this:
I'm happy to start a new branch with the start and finish lines and tp sectors on. The only proviso is I'd like to build it on a version which loses the line from takeoff to start- it just looks a lot better like that. Any problem if it's built on my latest, sorting out the issues with the task points array later? Also, since I'm still getting my head round some of what github does, do I need to put anything in my gh-pages branch so you can look at it?
My only concern with php code is that you can look at it, but can't actually do anything with it yourself without a server that will run it (and hold the database). I could, of course simply upload code that submits ajax requests to my own server with the same php on it.
On airspace I've looked at the UK kml file. Bad news is that it's a
cool 15 Mb. Good news is that it contains a lot of data we don't need.
Bad news is that neither geoJSON or kml recognises circles, and a lot of
airspace (ATZs, danger areas) is circular. Defining circles as polygons
seems to me to be inefficient. I think soluble but non-trivial.
Regards
…known issue with EW barographs)
Alter display of task information to show start, finish and TP numbers No longer show track from takeoff to start, or finish to landing in task layer (clearer display when we draw start and finish lines)