search

apps4av / avare

Avare Aviation GPS for Android
Other
155 stars 123 forks source link

V16 between CYN and ENO is incorrect #355

Closed n251ea closed 4 years ago

n251ea commented 4 years ago

When Avare expands the routing between CYN and ENO on V16 Avare produces the following: CYN LEBVE JIIMS BRIEF ENO which is incorrect

The correct waypoints are:

CYN LEBVE VCN BRIEF ENO

JIIMS and VCN are almost at the same LAT/LONG

JIIMS - 39-32-15.620N 074-58-01.720W VCN - 39-32-15.616N / 074-58-01.718W

reddn commented 4 years ago

I've recently messed with the CIFP data doing some other projects and found this problem to be interesting.

CIFP data gives fix GPS coordinates as DD MM SS.SS [note down to hundreths of a second]. which both JIIMS and VCN are the same (see below). On airnav.com it gives fix/naviad gps coordinates to thousandths of a second.

As you see at the bottom, i guess avare strips the fix names in the CIFP and only uses the sequence number and decimal lat/long. so im also assuming when you type in 'fix1 v16 fix2', it looks for the lat/long for fix1 and fix2 to, finds it in routes, then goes through each sequence between fix1 and fix2 andlooks at the fix/navaid db to get the fix name.

So maybe it only matches upto the hundred thousandths (5th number right of decimal) and moves on?

CIFP data >>: VCN SUSAD VCN K6011520VDL N39321562W074580172 N39321562W074580172W0100001201 NARCEDAR LAKE 236411711

V16 VCN SUSAER V16 1420VCN K6D 0V OL 065801270644 01900 58245181

SUSAEAENRT JIIMS K60 W R N39321562W074580172 W0121 NAR JIIMS 364001901

main.sq fix data >>: VCN 39.5376711111111 -74.9671438888889 VOR/DME CEDAR LAKE 115.20 -10 L 120.0 JIIMS 39.5376722222222 -74.9671444444444 YWAYPOINT JIIMS

main.db airways rows >>>

;V16|1260|38.7616138888889|-75.96005 V16|1270|38.8422555555556|-75.8843694444444 V16|1280|38.8922527777778|-75.83735 V16|1290|38.942975|-75.7898138888889 V16|1300|39.0610888888889|-75.6779583333333 V16|1310|39.2316466666667|-75.51597 V16|1320|39.4486694444444|-75.1276916666667 V16|1330|39.5376711111111|-74.9671438888889 [this is VCN on V16] V16|1340|39.6569472222222|-74.7398388888889 V16|1350|39.8173380555556|-74.4316258333333 V16|1360|40.0067555555556|-74.2512805555556 V16|1370|40.0993666666667|-74.1644916666667 V16|1380|40.2317944444444|-74.0662388888889 V16|1390|40.6328888888889|-73.7713888888889 V16|1400|40.8374361111111|-73.5451611111111 V16|1410|40.858875|-73.3752222222222 V16|1420|40.8900222222222|-73.1244972222222 V16|1430|40.9296180555556|-72.7988591666667 V16|1440|41.0142916666667|-72.6921777777778 V16|1450|41.0742805555556|-72.6163111111111

On Tue, Oct 29, 2019 at 6:24 PM n251ea notifications@github.com wrote:

When Avare expands the routing between CYN and ENO on V16 Avare produces the following: CYN LEBVE JIIMS BRIEF ENO which is incorrect

The correct waypoints are:

CYN LEBVE VCN BRIEF ENO

JIIMS and VCN are almost at the same LAT/LONG

JIIMS - 39-32-15.620N 074-58-01.720W VCN - 39-32-15.616N / 074-58-01.718W

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apps4av/avare/issues/355?email_source=notifications&email_token=AA4HTVVU2XZQTEUJXFBVG3DQRCZZXA5CNFSM4JGQLQR2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HVHBQQQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4HTVVP7BMGO2LERQWDTMTQRCZZXANCNFSM4JGQLQRQ .

n251ea commented 4 years ago

You maybe onto something. I just tried entering the flight plan of "CYN V16 VCN" this should come up in the flight plan as "CYN LEBVE VCN" but instead it came up as "CYN LEBVE JIIMS" so it lt looks like Avare is converting the waypoint to a lat/long and then using the first match it finds by using the first 5 digits to the right of the decimal place. I'm going to take a wild guess that intersections are searched before VORs in the database.

Two additional questions come to mind, assume that the search is expanded to the full lat/long location, what will happen with two colocated waypoints? There needs to be some sort of "order of operations" for example if a waypoint name is not specified then VORs are selected first then intersections?

On 2019-10-31 14:41, reddn wrote:

I've recently messed with the CIFP data doing some other projects and found this problem to be interesting.

CIFP data gives fix GPS coordinates as DD MM SS.SS [note down to hundreths of a second]. which both JIIMS and VCN are the same (see below). On airnav.com it gives fix/naviad gps coordinates to thousandths of a second.

As you see at the bottom, i guess avare strips the fix names in the CIFP and only uses the sequence number and decimal lat/long. so im also assuming when you type in 'fix1 v16 fix2', it looks for the lat/long for fix1 and fix2 to, finds it in routes, then goes through each sequence between fix1 and fix2 andlooks at the fix/navaid db to get the fix name.

So maybe it only matches upto the hundred thousandths (5th number right of decimal) and moves on?

CIFP data >>: VCN SUSAD VCN K6011520VDL N39321562W074580172 N39321562W074580172W0100001201 NARCEDAR LAKE 236411711

V16 VCN SUSAER V16 1420VCN K6D 0V OL 065801270644 01900 58245181

SUSAEAENRT JIIMS K60 W R N39321562W074580172 W0121 NAR JIIMS 364001901

main.sq fix data >>: VCN 39.5376711111111 -74.9671438888889 VOR/DME CEDAR LAKE 115.20 -10 L 120.0 JIIMS 39.5376722222222 -74.9671444444444 YWAYPOINT JIIMS

main.db airways rows >>>

;V16|1260|38.7616138888889|-75.96005 V16|1270|38.8422555555556|-75.8843694444444 V16|1280|38.8922527777778|-75.83735 V16|1290|38.942975|-75.7898138888889 V16|1300|39.0610888888889|-75.6779583333333 V16|1310|39.2316466666667|-75.51597 V16|1320|39.4486694444444|-75.1276916666667 V16|1330|39.5376711111111|-74.9671438888889 [this is VCN on V16] V16|1340|39.6569472222222|-74.7398388888889 V16|1350|39.8173380555556|-74.4316258333333 V16|1360|40.0067555555556|-74.2512805555556 V16|1370|40.0993666666667|-74.1644916666667 V16|1380|40.2317944444444|-74.0662388888889 V16|1390|40.6328888888889|-73.7713888888889 V16|1400|40.8374361111111|-73.5451611111111 V16|1410|40.858875|-73.3752222222222 V16|1420|40.8900222222222|-73.1244972222222 V16|1430|40.9296180555556|-72.7988591666667 V16|1440|41.0142916666667|-72.6921777777778 V16|1450|41.0742805555556|-72.6163111111111

On Tue, Oct 29, 2019 at 6:24 PM n251ea notifications@github.com wrote:

When Avare expands the routing between CYN and ENO on V16 Avare produces the following: CYN LEBVE JIIMS BRIEF ENO which is incorrect

The correct waypoints are:

CYN LEBVE VCN BRIEF ENO

JIIMS and VCN are almost at the same LAT/LONG

JIIMS - 39-32-15.620N 074-58-01.720W VCN - 39-32-15.616N / 074-58-01.718W

-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/apps4av/avare/issues/355?email_source=notifications&email_token=AA4HTVVU2XZQTEUJXFBVG3DQRCZZXA5CNFSM4JGQLQR2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HVHBQQQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4HTVVP7BMGO2LERQWDTMTQRCZZXANCNFSM4JGQLQRQ .

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links:

[1] https://github.com/apps4av/avare/issues/355?email_source=notifications&email_token=ALPNVB2WDSUNEQ2LDSDX63TQRMRFXA5CNFSM4JGQLQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECY2ZSA#issuecomment-548515016 [2] https://github.com/notifications/unsubscribe-auth/ALPNVB3R6752MGPJKOVJ4WDQRMRFXANCNFSM4JGQLQRQ

reddn commented 4 years ago

I think the idea of stripping the fix name from the waypoints db was to save space, but again, data is being duplicated by having the lat/long in two different places.

I was looking in the code, i dont see who calls it, but this code would look for a fix before a navaid https://github.com/apps4av/avare/blob/323feb390e01e0e3f92e821c6a7b93dc9a27f69f/app/src/main/java/com/ds/avare/content/LocationContentProviderHelper.java#L469

On Thu, Oct 31, 2019 at 3:04 PM n251ea notifications@github.com wrote:

You maybe onto something. I just tried entering the flight plan of "CYN V16 VCN" this should come up in the flight plan as "CYN LEBVE VCN" but instead it came up as "CYN LEBVE JIIMS" so it lt looks like Avare is converting the waypoint to a lat/long and then using the first match it finds by using the first 5 digits to the right of the decimal place. I'm going to take a wild guess that intersections are searched before VORs in the database.

Two additional questions come to mind, assume that the search is expanded to the full lat/long location, what will happen with two colocated waypoints? There needs to be some sort of "order of operations" for example if a waypoint name is not specified then VORs are selected first then intersections?

On 2019-10-31 14:41, reddn wrote:

I've recently messed with the CIFP data doing some other projects and found this problem to be interesting.

CIFP data gives fix GPS coordinates as DD MM SS.SS [note down to hundreths of a second]. which both JIIMS and VCN are the same (see below). On airnav.com it gives fix/naviad gps coordinates to thousandths of a second.

As you see at the bottom, i guess avare strips the fix names in the CIFP and only uses the sequence number and decimal lat/long. so im also assuming when you type in 'fix1 v16 fix2', it looks for the lat/long for fix1 and fix2 to, finds it in routes, then goes through each sequence between fix1 and fix2 andlooks at the fix/navaid db to get the fix name.

So maybe it only matches upto the hundred thousandths (5th number right of decimal) and moves on?

CIFP data >>: VCN SUSAD VCN K6011520VDL N39321562W074580172 N39321562W074580172W0100001201 NARCEDAR LAKE 236411711

V16 VCN SUSAER V16 1420VCN K6D 0V OL 065801270644 01900 58245181

SUSAEAENRT JIIMS K60 W R N39321562W074580172 W0121 NAR JIIMS 364001901

main.sq fix data >>: VCN 39.5376711111111 -74.9671438888889 VOR/DME CEDAR LAKE 115.20 -10 L 120.0 JIIMS 39.5376722222222 -74.9671444444444 YWAYPOINT JIIMS

main.db airways rows >>>

;V16|1260|38.7616138888889|-75.96005 V16|1270|38.8422555555556|-75.8843694444444 V16|1280|38.8922527777778|-75.83735 V16|1290|38.942975|-75.7898138888889 V16|1300|39.0610888888889|-75.6779583333333 V16|1310|39.2316466666667|-75.51597 V16|1320|39.4486694444444|-75.1276916666667 V16|1330|39.5376711111111|-74.9671438888889 [this is VCN on V16] V16|1340|39.6569472222222|-74.7398388888889 V16|1350|39.8173380555556|-74.4316258333333 V16|1360|40.0067555555556|-74.2512805555556 V16|1370|40.0993666666667|-74.1644916666667 V16|1380|40.2317944444444|-74.0662388888889 V16|1390|40.6328888888889|-73.7713888888889 V16|1400|40.8374361111111|-73.5451611111111 V16|1410|40.858875|-73.3752222222222 V16|1420|40.8900222222222|-73.1244972222222 V16|1430|40.9296180555556|-72.7988591666667 V16|1440|41.0142916666667|-72.6921777777778 V16|1450|41.0742805555556|-72.6163111111111

On Tue, Oct 29, 2019 at 6:24 PM n251ea notifications@github.com wrote:

When Avare expands the routing between CYN and ENO on V16 Avare produces the following: CYN LEBVE JIIMS BRIEF ENO which is incorrect

The correct waypoints are:

CYN LEBVE VCN BRIEF ENO

JIIMS and VCN are almost at the same LAT/LONG

JIIMS - 39-32-15.620N 074-58-01.720W VCN - 39-32-15.616N / 074-58-01.718W

-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/apps4av/avare/issues/355?email_source=notifications&email_token=AA4HTVVU2XZQTEUJXFBVG3DQRCZZXA5CNFSM4JGQLQR2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HVHBQQQ , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AA4HTVVP7BMGO2LERQWDTMTQRCZZXANCNFSM4JGQLQRQ

.

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links:

[1]

https://github.com/apps4av/avare/issues/355?email_source=notifications&amp;email_token=ALPNVB2WDSUNEQ2LDSDX63TQRMRFXA5CNFSM4JGQLQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECY2ZSA#issuecomment-548515016 [2]

https://github.com/notifications/unsubscribe-auth/ALPNVB3R6752MGPJKOVJ4WDQRMRFXANCNFSM4JGQLQRQ

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/apps4av/avare/issues/355?email_source=notifications&email_token=AA4HTVXCIRCJGSWFIT6EZXTQRMT2HA5CNFSM4JGQLQR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECY462Q#issuecomment-548523882, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4HTVROZBKSWTZCQ567MYLQRMT2HANCNFSM4JGQLQRQ .

n251ea commented 4 years ago

Would it simply be easier to match longer than 5 decimal places? JIMMS and CYN would then be different and CYN would be picked up. Sounds strange that you would need to rely on more than 5 decimal places but so be it

possibly these lines? LocationContentProviderHelper.java:264: params.put(LATITUDE, Double.toString(Helper.truncGeo(c.getDouble(4)))); LocationContentProviderHelper.java:265: params.put(LONGITUDE, Double.toString(Helper.truncGeo(c.getDouble(5))));

apps4av commented 4 years ago

databases has correct decimals places. JIIMS|39.5376722222222|-74.9671444444444|YWAYPOINT|JIIMS CYN|39.8173380555556|-74.4316258333333|VORTAC|COYLE 113.40|-10|H||203.4

I can look into truncGeo. I have forgotten why I used truncGeo(), removing it could break a lot of code.

apps4av commented 4 years ago

trunCgeo could be related to long press on map.

n251ea commented 4 years ago

Should be CVNSent from my cell phone  -------- Original message --------From: Zubair Khan notifications@github.com Date: 7/6/20 8:20 PM (GMT-05:00) To: apps4av/avare avare@noreply.github.com Cc: n251ea jeff@bubble.org, Author author@noreply.github.com Subject: Re: [apps4av/avare] V16 between CYN and ENO is incorrect (#355) databases has correct decimals places. JIIMS|39.5376722222222|-74.9671444444444|YWAYPOINT|JIIMS CYN|39.8173380555556|-74.4316258333333|VORTAC|COYLE 113.40|-10|H||203.4 I can look into truncGeo. I have forgotten why I used truncGeo(), removing it could break a lot of code.

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe. [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/apps4av/avare/issues/355#issuecomment-654527714", "url": "https://github.com/apps4av/avare/issues/355#issuecomment-654527714", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

n251ea commented 4 years ago

oops, should be VCN

On 7/6/20 8:23 PM, Jeffrey Ross wrote:

Should be CVN

Sent from my cell phone

Should be CVNSent from my cell phone

-------- Original message -------- From: Zubair Khan notifications@github.com Date: 7/6/20 8:20 PM (GMT-05:00) To: apps4av/avare avare@noreply.github.com Cc: n251ea jeff@bubble.org, Author author@noreply.github.com Subject: Re: [apps4av/avare] V16 between CYN and ENO is incorrect (#355)

databases has correct decimals places. JIIMS|39.5376722222222|-74.9671444444444|YWAYPOINT|JIIMS CYN|39.8173380555556|-74.4316258333333|VORTAC|COYLE 113.40|-10|H||203.4

I can look into truncGeo. I have forgotten why I used truncGeo(), removing it could break a lot of code.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apps4av/avare/issues/355#issuecomment-654527714, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALPNVB45LXS2QJX7GUYAAT3R2JS5FANCNFSM4JGQLQRQ.

-------- Original message --------From: Zubair Khan notifications@github.com Date: 7/6/20 8:20 PM (GMT-05:00) To: apps4av/avare avare@noreply.github.com Cc: n251ea jeff@bubble.org, Author author@noreply.github.com Subject: Re: [apps4av/avare] V16 between CYN and ENO is incorrect (#355) databases has correct decimals places. JIIMS|39.5376722222222|-74.9671444444444|YWAYPOINT|JIIMS CYN|39.8173380555556|-74.4316258333333|VORTAC|COYLE 113.40|-10|H||203.4 I can look into truncGeo. I have forgotten why I used truncGeo(), removing it could break a lot of code.

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe. [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/apps4av/avare/issues/355#issuecomment-654527714", "url": "https://github.com/apps4av/avare/issues/355#issuecomment-654527714", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

apps4av commented 4 years ago

truncGeo is used for display purposes. If its too long, screen will fill up and overflow. I will increase to 6 digits but will need to check in a lot of places.

apps4av commented 4 years ago

truncGeo is not the problem. I checked.

apps4av commented 4 years ago

The main issue is that fixes are preferred over navaids in search.

apps4av commented 4 years ago

Fixed.