search

ericberman / MyFlightbookWeb

The website and service for MyFlightbook
49 stars 18 forks source link

Noting arrival and departures, searching on them #327

Closed KayRJay closed 5 years ago

KayRJay commented 5 years ago

Generally, people enter a route from beginning to end. The first airport is a departure, the last an arrival, and any intermediate airports on the route are both arrival and departures. It would thus be easy to identify for each flight, for each airport, where departures and arrivals occurred.

Search now supports finding airports "visited" (using a complex scheme). If arrival and departures were associated with the airports on a route, the user could specify a search using a UI like this:

Flight visited any of these airports (Click to Hide): [?]

ABC DEF GHI<

would find flights that departed from ABC, "visited" DEF and arrived at GHI.

KayRJay commented 5 years ago

Mardown got me. The first airport in the route would have a "greater than" sign so it would be ">ABC DEF GHI<"

ericberman commented 5 years ago

One minor challenge: can’t use “<” because it’s used for injection attacks on the web. Well, OK, can use it, but things get a lot more complicated.

From: KayRJay notifications@github.com Sent: Monday, June 24, 2019 5:54 PM To: ericberman/MyFlightbookWeb MyFlightbookWeb@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [ericberman/MyFlightbookWeb] Noting arrival and departures, searching on them (#327)

Mardown got me. The first airport in the route would have a "greater than" sign so it would be ">ABC DEF GHI<"

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericberman%2FMyFlightbookWeb%2Fissues%2F327%3Femail_source%3Dnotifications%26email_token%3DAD5RM5VEYBG2WBNFOKDIL4DP4FUDBA5CNFSM4H3DNH3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYOUJBI%23issuecomment-505234565&data=02%7C01%7C%7C6bbc3f8e8aa0420f6d9c08d6f907a1e4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636970208505328411&sdata=n52DxzqwavfWbGWSCgvRx%2BSHKglGt45sY4jE3yEEmnA%3D&reserved=0, or mute the threadhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAD5RM5QQRF6CG4P2MJOW5MDP4FUDBANCNFSM4H3DNH3A&data=02%7C01%7C%7C6bbc3f8e8aa0420f6d9c08d6f907a1e4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636970208505338392&sdata=uTyWVBFV%2FJaQI9NFzACZslHRWrKKAGP%2FopyQGKb7Xyw%3D&reserved=0.

KayRJay commented 5 years ago

I just thought the single character was “natural”. Unfortunately, there’s no easy way to type a right or left arrow. You could do something like "arr:ABC DEF dep:GHI” in queries. The specific notation device isn’t important. The functionality of being able to search for arrivals or departures at a given airport is what I was after ...

On Jun 24, 2019, at 9:42 PM, Eric Berman notifications@github.com wrote:

One minor challenge: can’t use “<” because it’s used for injection attacks on the web. Well, OK, can use it, but things get a lot more complicated.

From: KayRJay notifications@github.com Sent: Monday, June 24, 2019 5:54 PM To: ericberman/MyFlightbookWeb MyFlightbookWeb@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [ericberman/MyFlightbookWeb] Noting arrival and departures, searching on them (#327)

Mardown got me. The first airport in the route would have a "greater than" sign so it would be ">ABC DEF GHI<"

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericberman%2FMyFlightbookWeb%2Fissues%2F327%3Femail_source%3Dnotifications%26email_token%3DAD5RM5VEYBG2WBNFOKDIL4DP4FUDBA5CNFSM4H3DNH3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYOUJBI%23issuecomment-505234565&data=02%7C01%7C%7C6bbc3f8e8aa0420f6d9c08d6f907a1e4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636970208505328411&sdata=n52DxzqwavfWbGWSCgvRx%2BSHKglGt45sY4jE3yEEmnA%3D&reserved=0, or mute the threadhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAD5RM5QQRF6CG4P2MJOW5MDP4FUDBANCNFSM4H3DNH3A&data=02%7C01%7C%7C6bbc3f8e8aa0420f6d9c08d6f907a1e4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636970208505338392&sdata=uTyWVBFV%2FJaQI9NFzACZslHRWrKKAGP%2FopyQGKb7Xyw%3D&reserved=0. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ericberman/MyFlightbookWeb/issues/327?email_source=notifications&email_token=AEBRDED5DRX25F5DBJAQGNDP4GHYVA5CNFSM4H3DNH3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYO4Y3Q#issuecomment-505269358, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBRDEB2WUMAZJRODPPQJQTP4GHYVANCNFSM4H3DNH3A.

ericberman commented 5 years ago

Totally understood. It was just a note.

ericberman commented 5 years ago

Probably do "^" as a prefix or suffix to indicate arrival or departure. Or could use / and \, since that looks like a departure and a landing (too cute by half - but I bet people use / as a separator too). I thought about using *, but that looks like a wildcard. ""$" and "^" are regular expression anchors, so that's why I'd consider using "^". Esoteric as all hell. :)

KayRJay commented 5 years ago

I kinda like ^, as it definitely connotes altitude. Too bad there’s no upside down character like it on the keyboard. Agree re / and . also.

I suppose it is ok to use the same character as a prefix and a suffix. Let’s also consider what would happen if you recorded the runway:

^ABC DEF GHI^ with runways becomes ^KAC:xx DEF GHI^:yy

that’s sorta noisy.

You don’t want to infer from the route ABC DEF GHI that ABC is an arrival, GHI a departure and DEF both? This seems very natural to me, and doesn’t require extra parsing or the user to enter appropriate extra symbols. You could have a check box or preference to disable this treatment when the route is entered. But I’m not sure who would object to that interpretation.

Ken

On Jun 26, 2019, at 4:54 PM, Eric Berman notifications@github.com wrote:

Probably do "^" as a prefix or suffix to indicate arrival or departure. Or could use / and , since that looks like a departure and a landing (too cute by half - but I bet people use / as a separator too). I thought about using *, but that looks like a wildcard. ""$" and "^" are regular expression anchors, so that's why I'd consider using "^". Esoteric as all hell. :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ericberman/MyFlightbookWeb/issues/327?email_source=notifications&email_token=AEBRDEET2ETDJ2AXO2OQZLTP4PXRZA5CNFSM4H3DNH3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYVBH5Y#issuecomment-506074103, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBRDEAU2Z5FSBTGW4FZGYLP4PXRZANCNFSM4H3DNH3A.

ericberman commented 5 years ago

Let's leave runways out of this - I've not figured out a good standardized/searchable way to do runways yet (or if it even matters). But I was proposing the reverse: your example above has the user log ^ at the start/end of the route. That's silly - as you quite correctly point out, ABC is departure, GHI is arrival (OK, you actually reversed those, but I assume that was an oops) and DEF is both. I already do this where I need to figure out a "From" or a "To", be it visited airports or EASA print layout.

I'll assert here that requiring any changes to how people log the route of their flight is almost certainly a non-starter; but the feature request here is to be able to search for flights where you departed ABC, for example. Right now, if you search for "ABC", you'd match both flights "ABC DEF" as well as "DEF ABC". I think you could just use "^" as a search character to mean "only match as departure or arrival", so searching for "^ABC" would match "ABC DEF" but not "DEF ABC", and searching for "ABC^" would match "DEF ABC" but not "ABC DEF". You can thus do the search you want without having to log your flights any differently. I.e., in MySQL speak, searching for "^ABC" translates to "LIKE 'ABC%'", "ABC" translates to "LIKE '%ABC%'", and "ABC^" translates to "LIKE '%ABC'"

KayRJay commented 5 years ago

Well, Eric, we have a disconnect here. Or, rather, we are in violent agreement.

I was not at all suggesting that people would change the way they enter a route. As I said, you can infer that the first airport is a departure airport, the last an arrival airport and the ones in between are both. (Yes, when I said it backwards, that was an oops.) Your explanation of how search would work is exactly what I had in mind.

It was only in search criteria that you would allow a specification of arrival or departure, or either, from an airport. The syntax for the search criteria, including the arrive/depart notation should be clean and simple. Without runways, this does seem pretty straightforward. However ...

Now I know you said leave runways out of it, but I think you have to plan ahead here. If you are ever going to want to support runways, you’ll want to support searches (not just data entry) that specify arriving, departing or either on a given runway too. Put aside for a moment whether doing anything wrt runways is important or worth doing. I just think you don’t want to do anything to preclude it working in a nice way.

Assume, for the sake of argument, that the way you enter an airport with the runway is the nice, natural notation ABC:04 or DEF:22L, for example. No ambiguity could arise because there is a colon and no space between the airport code and the runway number, which is of course always two digits, and is sometimes followed by a single letter when there are parallel runways. You can easily infer arrival and departure airports from the entered route, with or without runways.

Now thinking about search, there are two topics to consider: (1) how does the user specify arrival vs departure, and (2) how does he specify a runway in the query? It seems you’d want to use a syntax for the search by runway that is similar to the way the route is entered (like a colon), and that the indicator for arrival or departure should be simple and intuitive.

If you use the :runway notation, what’s the best way to denote arrival or departure? One way is the prefix/suffix notation I originally suggested. The angle brackets seemed nice because > as a prefix looks like arrival, and < as a suffix looks like departure. But the SQL injection concern complicates things. And having two suffixes is messy.

Sine the runway identification follows the airport code, perhaps the idea of prefix and suffix should be discarded. After all, in English we think of departure FROM an airport and arrival AT an airport. The direction, in English, precedes the airport ID.

Thus, the departure/arrival indicator would be a prefix, and runways a suffix. Now things are become a little more clear. Use the at-sign @ for arrival AT an airport and the up-arrow ^ for departure FROM an airport. The @ is pretty obvious and the ^ works too, as it signifies “up”.

Thus, in search criteria, we have @ABC as an arrival airport, and ^ABC as a departure airport. Even when runways are specified, the meaning of the search specification (while it might look like a badly formed route at first glance) is clean and clear — @ABC:04 DEF ^GHI means, quite simply, arrival at ABC on runway 04, departure from GHI on any runway, and either arrival or departure on any runway at DEF. (Of course these criteria could be ANDed or ORed or negated if/when you supported those options.)

I leave for another discussion the merits of supporting runways, other than to say I can imagine it being useful because of a pilot’s knowledge of obstacles or length or other runway-specific issues, even in the absence of any automatic lookup of runway characteristics. (Wouldn’t it be cool, though, to search for flights landing on runways less than x feet long?)

Enough for now ...

Ken

Sent from my iPad

On Jun 26, 2019, at 10:21 PM, Eric Berman notifications@github.com wrote:

Let's leave runways out of this - I've not figured out a good standardized/searchable way to do runways yet (or if it even matters). But I was proposing the reverse: your example above has the user log ^ at the start/end of the route. That's silly - as you quite correctly point out, ABC is departure, GHI is arrival (OK, you actually reversed those, but I assume that was an oops) and DEF is both. I already do this where I need to figure out a "From" or a "To", be it visited airports or EASA print layout.

I'll assert here that requiring any changes to how people log the route of their flight is almost certainly a non-starter; but the feature request here is to be able to search for flights where you departed ABC, for example. Right now, if you search for "ABC", you'd match both flights "ABC DEF" as well as "DEF ABC". I think you could just use "^" as a search character to mean "only match as departure or arrival", so searching for "^ABC" would match "ABC DEF" but not "DEF ABC", and searching for "ABC^" would match "DEF ABC" but not "ABC DEF". You can thus do the search you want without having to log your flights any differently. I.e., in MySQL speak, searching for "^ABC" translates to "LIKE 'ABC%'", "ABC" translates to "LIKE '%ABC%'", and "ABC^" translates to "LIKE '%ABC'"

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

ericberman commented 5 years ago

My point about runways was that I think it's an independent variable, so no need to complicate it. I'm confident that doing ^ABC or ABC^ doesn't preclude a runway solution in the future. I'm particularly not confident, though, that doing the runways in the way you suggest is feasible. So I can try to solve both of them in one integrated solution, or I can solve what I know how to solve.

Some specific issues to address with the runway suffix notation are the choice of delimiter character (":" is actually used by some people; that's an easy one), but avoiding a nomenclature that confuses runways with airports is harder. 2-digit runways is easy; 2-digit plus L/R/C can conflict with airports. E.g., "27C" is an airport, "14L" is an airport", etc. And "RWY" is an airport. It may make more sense to leave the runways outside of the route. E.g., in the same way that I have an "Approach Names" property to capture the approaches that you do, it may make sense to have a "Runways" property. And then you could put something like (off the top of my head) "LND-14L@ORD DEP-32R@JFK" or something like that to indicate landing on 14L at Chicago and departing 32R at New York. That avoids potential confusion between runways and airports. I don't know if that's the right way to do it either (or if even that provides value over just putting it into the comments), but the point is that it may make sense to keep it separate from "Route".

See also https://myflightbookblog.blogspot.com/2017/11/logging-landingstakeoffs-and-approaches.html for why I specifically made a tradeoff between highly normalized and denormalized data for landings; I would not be surprised if I dive into runways and find it to be the same thing.

So solve one issue that you know how to solve, solve another issue later. I don't think depart/arrival airport and runways are conflated.

KayRJay commented 5 years ago

Well, it does seem that airports and runways have a lot to do with one another, so they are not complertely independen! 😃

Can you explain what is in feasible about the approach I suggest? Parsing a string of arrival and departure airports with runways using my notation isn’t complex. On the other hand, using the same ^ (up-arrow) on both sides of an airport code is a little more difficult for the user, especially if you are going to support runways as I suggest.

As to solving both requirements (arrival vs departure and runway numbers) in one integrated solution that you may not (yet) see vs solving what you know how to solve ... that sounds like a dilemma, but it’s not. You’re good as long as what you do implement for one requirement leaves open the possibility of eventually addressing both requirements in an integrated solution.

Is there something that makes @ABC:04 or ^DEF:22 difficult? Even with the “homonyms” of 27C and 14L being airports, I don’t see where the confusion would arise. The string ^ABC:27C RWY 27C:04R @DEF is unambiguous as far as I can tell. Parsing this seems straightforward:

I don’t see at all what else this could mean. Maybe I’m dense, but I just don’t understand your objection to this (or similar) syntax.

Not having learned much at all about IFR flying, it’s not wise of me to comment on the association between runways and approaches, but I do see that you could tie them together. But for me, as a VFR newbie, I don’t “do” approaches (yet ... and it will be a long time before I do). It would be so much more convenient for non-VFR flights to enter the runway as above, as part of the route.

We may (or may not) be confusing route specifications with query criteria. As we both realize, I think, it’s easy to infer arrival and departures. So no extra syntax is needed when routes are entered (except to specify the runway). It just makes sense that the query criteria should have similar syntax.

The syntax you propose, LND-14L@ORD DEP-32R@JFK, might work as a query specification. Having the runway first would probably be ok, I think. But syntax you propose requires a bit more typing. In my proposal, these two criteria would be ^14L:ORD and @32R:JFK. Using a single character ... ^ or @ ... is obviously more concise than using four characters ... LND- and DEP- ...to designate the same thing. I haven’t looked, but LND and DEP could be airports too, so there is the potential for confusion.

Bottom line, I naturally prefer my syntax proposal, which just seems visually more obvious and clean than the alternative. I addition, since the runway is subordinate to the airport (right?!), it seems logical to have the runway follow the airport. However, I do acknowledge that people write and say “27 June” and “June 27”, but it’s just seems more natural to me (as an American) to use the latter form.

I do think having runway info in the route is much better than in comments. Structured data is always easier to search (and index, if needed) than unstructured text. I see your argument about not doing so for different IFR approaches, but I have nothing intelligent to say about the pros and cons of putting it in free text (comments or "Approach Description").

Now, having said all that, until I read your blog post, I didn’t realize you recognized this string

      [#][Approach type][Runway]@[Airport code]

with hints as you describe in your blog post. I can understand how you might be committed to maintaining support for that notation, but I do wonder how many people use it. Since it is only in comments, and not in a structured field (like route, or a query criterion), there is no conflict with adding the more structured approach (pun not intended).

I agree that it makes sense, given the likely queries, to allow the user to record the number of approaches / landings of a given type in a structured way, while recording the approach description in a free-form text field. I don’t see the same situation with runways, though. I would be surprised if you found runway support similar in some way to the approaches issue as you “dive into” it.

I am not suggesting that departing/arrival airports and runways are conflated. I am suggesting that they are “related”, and most importantly that both be treated in a structured way to better support searches on them. I know you now don’t lookup runway info (like length) from a database. But, if you did someday, queries like “landings on runways less than a specified length” and more become possible.

Your syntax template above kind of reminds me of the Excel notion for referencing cells in another worksheet (and of course I don’t need to remind you of that syntax!). Since I am not familiar with all possible approach types, I can’t judge whether there is possible ambiguity between an approach type and a runway spec. Does it make sense to specify an approach without a runway, or a runway without an airport code (even with a required @)? Could “3ILS@” be confused with 3 landings at an airport named ILS?

It seems it would be a lot easier to implement (structured rather than full text) queries if the route is entered in a structured format (with arrivals and departures and possibly runways).

Always so much to think about as you consider these things ...

Ken

On Jun 27, 2019, at 2:10 PM, Eric Berman notifications@github.com wrote:

My point about runways was that I think it's an independent variable, so no need to complicate it. I'm confident that doing ^ABC or ABC^ doesn't preclude a runway solution in the future. I'm particularly not confident, though, that doing the runways in the way you suggest is feasible. So I can try to solve both of them in one integrated solution, or I can solve what I know how to solve.

Some specific issues to address with the runway suffix notation are the choice of delimiter character (":" is actually used by some people; that's an easy one), but avoiding a nomenclature that confuses runways with airports is harder. 2-digit runways is easy; 2-digit plus L/R/C can conflict with airports. E.g., "27C" is an airport, "14L" is an airport", etc. And "RWY" is an airport. It may make more sense to leave the runways outside of the route. E.g., in the same way that I have an "Approach Names" property to capture the approaches that you do, it may make sense to have a "Runways" property. And then you could put something like (off the top of my head) "LND-14L@ORD DEP-32R@JFK" or something like that to indicate landing on 14L at Chicago and departing 32R at New York. That avoids potential confusion between runways and airports. I don't know if that's the right way to do it either (or if even that provides value over just putting it into the comments), but the point is that it may make sense to keep it separate from "Route".

See also https://myflightbookblog.blogspot.com/2017/11/logging-landingstakeoffs-and-approaches.html for why I specifically made a tradeoff between highly normalized and denormalized data for landings; I would not be surprised if I dive into runways and find it to be the same thing.

So solve one issue that you know how to solve, solve another issue later. I don't think depart/arrival airport and runways are conflated.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

ericberman commented 5 years ago

What you suggest isn't inherently infeasible. It's just got issues to work through. At the moment, airports in the route are separated by ANY non-alphanumeric non-@ character. And people do use colons, slashes, hyphens, all sorts of characters. ("@" is a special prefix in the route field that precedes a latitude longitude or explicitly biases towards a navaid over an airport). So, to one question above, "ABC:27C RWY 27C:04R @def" is read as a sequence of airports: ABC, 27C (yes, that's an airport), RWY (yes, that's an airport), 27C, 04R (happens not to currently be an airport), followed by a navaid DEF. Definitely not what you are asking for. People use colons already simply as delimiters.

So the real requirement if you want to do runways inline is to find a delimiter that people aren't using and then take that away, reserving it for use in runway designation. But if it's an obscure delimiter, then it will be hard for them to figure out how to do it.

Note that there is nothing preventing you from following your own convention here. If you want to notate your flight from ABC to DEF with runways 01 and 35L, you can log it as "ABC:01 DEF:35L". Not a problem. You can make up any syntax you want here, actually. But the "35L" will show up in your visited airports list and map.

The approach syntax is used by a lot of people because it is supported by an approach helper on the mobile apps that build it for you, but if you don't quite follow it, there's absolutely no downside. It just doesn't get recognized/translated into plain text. The key thing is that you can log it and you can search on it; my syntax is just a suggestion for a readable format, but the approach description is a free-form text field and you can follow any convention you like. So to your question of "3ILS@", it doesn't get confused with an airport "ILS" or "3ILS" because it doesn't go in the "Route" field.

Doing a similar thing in a "Runways" property would provide the same benefits: you can use whatever convention you want to make up (so you don't have to learn a pre-defined one) and search for it, and there would be no ambiguity with the route field. The runway is indeed associated with an airport, but it is not part of your "route" per se. You could follow any syntax you like on this, and then search on that syntax, unambiguously. Frankly, if only for that reason, I'm inclined to go that direction.

Taking a step back here, there are two independent scenarios being proposed to address: a) I want to search for flights where I departed or arrived at an airport. This, we agree, can be done without changing how a route is recorded - it's just a trick in search syntax. b) I want to search for flights that used a particular runway at a particular airport. This does require some sort of logging - somewhere - of which runway was used at which airport; after all, you can't search for information that isn't recorded. That can either be in the route field directly, as you propose, or it can be in a separate runway description.

Issue #332 tracks (b). Let's take that out of here; this is already waaaaay too long a thread on searching for runways in an issue that is talking about distinguishing departure and arrival airports.

KayRJay commented 5 years ago

Inline as usual ...

Sent from my iPad

On Jun 29, 2019, at 12:59 PM, Eric Berman notifications@github.com wrote:

What you suggest isn't inherently infeasible. It's just got issues to work through. At the moment, airports in the route are separated by ANY non-alphanumeric non-@ character.

Ok, but most often the space (blank) will be used, right? And people do use colons, slashes, hyphens, all sorts of characters. ("@" is a special prefix in the route field that precedes a latitude longitude or explicitly biases towards a navaid over an airport).

Only if you let them do so. 😃. If the only character that delimits one runway from another is a space, then the strings between spaces can be parsed in a strict way.

I now understand “@“ is special (though I don’t know how you’d use it). So instead of “@“ for arrival, I think you could use “>”.

So, to one question above, "ABC:27C RWY 27C:04R @def" is read as a sequence of airports: ABC, 27C (yes, that's an airport), RWY (yes, that's an airport), 27C, 04R (happens not to currently be an airport), followed by a navaid DEF. Definitely not what you are asking for. People use colons already simply as delimiters.

Yes the colon is a delimiter, but so is a space (or should be). I don’t see why you’d read 27C in ABC:27C as an airport. The next airport in the route follows a space. The string in a route between spaces is an airport, and possibly includes a runway. And, in a query criterion, there might also be an arrival/departure specification, like ^ABC:24C. I just don’t see the ambiguity if you respect the space.

Are you being too liberal in syntax checking? If you enforce a given format, with errors to the user for malformed entries, I don’t see the problem. Thus, these are the rules for in a complete landing or take-off spec:

The route now is minimally parsed, I guess. But with strict parsing you can validate the legality (format) of the entry (though perhaps not the airport code or runway info, but only because don’t have/get that info), and record it in a structured way.

Note that there is nothing preventing you from following your own convention here. If you want to notate your flight from ABC to DEF with runways 01 and 35L, you can log it as "ABC:01 DEF:35L". Not a problem. You can make up any syntax you want here, actually. But the "35L" will show up in your visited airports list and map.

Why allow the user to make up syntax? There is no reason to do so are far as I can tell. I suppose you can call this freedom a “benefit”, but this pales in value, in my view, to the benefits of a more structured approach: the airport info is clean and validated (to some extent) and is readily searchable. The approach syntax is used by a lot of people because it is supported by an approach helper on the mobile apps that build it for you, but if you don't quite follow it, there's absolutely no downside. It just doesn't get recognized/translated into plain text.

Right, I get that. All fine. The key thing is that you can log it and you can search on it; my syntax is just a suggestion for a readable format, but the approach description is a free-form text field and you can follow any convention you like. So to your question of "3ILS@", it doesn't get confused with an airport "ILS" or "3ILS" because it doesn't go in the "Route" field.

Free-text queries are imprecise. Specs in the route would not / should not be. Doing a similar thing in a "Runways" property would provide the same benefits: you can use whatever convention you want to make up (so you don't have to learn a pre-defined one) and search for it, and there would be no ambiguity with the route field.

I don’t see why this is a benefit. Entering random text is great for some things, but to me the structured and validated approach offers much greater benefits than allowing the user to make up whatever format he likes (and may fail to follow with every flight he enters).
The runway is indeed associated with an airport, but it is not part of your "route" per se.

Sure it is, strictly speaking. The route includes not only the airports I use, but my path over the ground between them (which is fully recorded the the telemetry). My actual, physical route includes a southernly departure at one airport and a westerly landing at another.
You could follow any syntax you like on this, and then search on that syntax, unambiguously. Frankly, if only for that reason, I'm inclined to go that direction.

Even if users were to enter routes using the proposed syntax, and reliability did so, a text-based query for “27C” is ambiguous. It would find airports and runways that match that string, when the user wanted only the runway. With a text search you could limit the result to runways only (Find flights matching “:27C” ...), but I’m not sure that’s useful. With a text search you could not limit searches to airports only.

If “Find flights visiting these airports ...” passed the query spec, the search using the structured info would not be ambiguous. Both the data entry and non-free-text search criteria would be syntax checked.

Taking a step back here, there are two independent scenarios being proposed to address: a) I want to search for flights where I departed or arrived at an airport. This, we agree, can be done without changing how a route is recorded - it's just a trick in search syntax.

Maybe not really a trick in search syntax ... it’s really inferring arrival/departure from the order of airports in a route, and use of an explicit modifier in a search criterion. b) I want to search for flights that used a particular runway at a particular airport. This does require some sort of logging - somewhere - of which runway was used at which airport; after all, you can't search for information that isn't recorded. That can either be in the route field directly, as you propose, or it can be in a separate runway description.

Issue #332 tracks (b). Let's take that out of here; this is already waaaaay too long a thread on searching for runways in an issue that is talking about distinguishing departure and arrival airports.

Right, that’s why I made Github entry #332 for the runway discussion, separating it from #327. Feel free, if it’s possible, to transfer all this text to #332, and clean up #327 ... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

ericberman commented 5 years ago

Technical note to self, after looking at the code: right now the flight query object doesn't pass a string for the airports; it passes a normalized set of airports (i.e., broken at non-alphanumeric). So I could add this to the website now, but at the moment I'd have to update the mobile apps to support this.

ericberman commented 5 years ago

Implemented on website. Separate bugs in iOS and Android track implementation (support for "!") on those respective platforms. FAQ tips and tricks also describes this. Yes, I'm keeping it subtle.

KayRJay commented 5 years ago

Very nice. Thanks for doing this too. I feel like I’ve made some sort of contribution, but I know I’ve also taken a lot of your time in doing things like this.

Yes, you are keeping it subtle. That will certainly limit the use of this feature. Perhaps someday you’ll post a blog entry about “little known features of MyFlightbook” ...

I’ll try this again when I get back ...

Thanks!

Ken

Sent from my iPad

On Jul 3, 2019, at 2:58 AM, Eric Berman notifications@github.com wrote:

Implemented on website. Separate bugs in iOS and Android track implementation (support for "!") on those respective platforms. FAQ tips and tricks also describes this. Yes, I'm keeping it subtle.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

ericberman commented 5 years ago

You are absolutely making a contribution - I wouldn't be doing these features if the goal were simply to shut you up. :) I see value in them.

But yes, I absolutely subscribe to a scalable UI philosophy. Make the most common scenarios discoverable, make the less common scenarios doable. There's LOTS of hidden tips/tricks that people find but only at the point where it occurs to them to look for it. I might put a "[?]" hover tip on this one...

KayRJay commented 5 years ago

I appreciate that, Eric … sorry can’t contribute code, but you probably wouldn’t want that anyway!

As far as a scalable UI, I appreciate and understand that too. The only counter is that if the features aren’t “first class” in the UI itself, the documentation and help and FAQs should make these features easy/easier to find.

Thanks …

Ken

P.S. Great diving in Komodo. Dragons will be on our last day ...

On Jul 3, 2019, at 9:15 AM, Eric Berman <notifications@github.com mailto:notifications@github.com> wrote:

You are absolutely making a contribution - I wouldn't be doing these features if the goal were simply to shut you up. :) I see value in them.

But yes, I absolutely subscribe to a scalable UI philosophy. Make the most common scenarios discoverable, make the less common scenarios doable. There's LOTS of hidden tips/tricks that people find but only at the point where it occurs to them to look for it. I might put a "[?]" hover tip on this one...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ericberman/MyFlightbookWeb/issues/327?email_source=notifications&email_token=AEBRDEGKCWGA6KOWP6SWYODP5PVSBA5CNFSM4H3DNH3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZC4QWA#issuecomment-507889752, or mute the thread https://github.com/notifications/unsubscribe-auth/AEBRDEB5ZLX5REFG6Q5FLBDP5PVSBANCNFSM4H3DNH3A.