When will corrected coordinates be provided in PQs?

[+MartyBartfast]

 

Waaay back in 2011 when the corrected co-ordinates feature was added  it was stated that:

Quote

(Please note: Pocket Queries will include only the original cache coordinates for now, however that functionality will be added in a followup release).

Here we are 11+ years on and it hasn't been implemented yet, is there any plan to do this?
 

 

[+M.B.E.S.]

6 hours ago, MartyBartfast said:

 

Waaay back in 2011 when the corrected co-ordinates feature was added  it was stated that:

Here we are 11+ years on and it hasn't been implemented yet, is there any plan to do this?
 

 

Just verified it. The Pocket Query contains 1 co-ordinate per cache (see wpt-element in .GPX file), which will be the corrected one if it has been corrected. Otherwise it will be the bogus.

[+Viajero Perdido]

But the original coordinates are lost, and I don't believe there's a way to determine whether the supplied coords are original or corrected.

 

But the API provides both.  (In Locus Map: "Update cache" --> both coords now shown.)

 

It's a bit eccentric that the API provides more cache info than a PQ.  Both specs seem to be frozen in time, but the API is newer.

[+MartyBartfast]

1 hour ago, M.B.E.S. said:

Just verified it. The Pocket Query contains 1 co-ordinate per cache (see wpt-element in .GPX file), which will be the corrected one if it has been corrected. Otherwise it will be the bogus.

But there's no way to know which co-ords the PQ is providing. Ideally it should provide both, alternatively it would be useful if there was some flag to indicate which it's giving, but the way it is being done is pretty rubbish.

[+Mausebiber]

12 minutes ago, MartyBartfast said:

But there's no way to know which co-ords the PQ is providing

 

When you create your query, why don't you just filter for solved coordinates?

 

 

 

 

[+MartyBartfast]

1 hour ago, Mausebiber said:

When you create your query, why don't you just filter for solved coordinates?

Because then, all those PQs I've got to cover my home area will need to be doubled - one set for Solved co-ords, and another set for Unsolved co-ords.

[+JL_HSTRE]

On 2/26/2023 at 12:35 PM, Viajero Perdido said:

It's a bit eccentric that the API provides more cache info than a PQ.

 

PQs are limited by GPX file format. I don't think the API has that limitation.

[+Viajero Perdido]

But GPX is XML, which is extensible.  To be clean about it, all they need is to bump the version number, and include that version as an option in the combo box that's hidden away somewhere.

 

Of course, the default behaviour of XML parsers is to ignore elements that aren't expected, no?

 

(I may be off on the details; haven't used XML in ~15 years.)

 

My guess: more important things to work on...  I haven't noticed any activity on PQ generation almost as long as I've been caching, other than to give the odd-numbered-PQ server a smack occasionally when it acted up.  (Really.)  Oh, and occasional increases to the limits, thank you.

 

Edited February 28, 2023 by Viajero Perdido

[+Hügh]

20 hours ago, Viajero Perdido said:

extensible

 

eXtensible, one might say.

 

But is such an extension even necessary? Maybe I'm wrong, but I think the format includes support for child waypoints. The posted coordinates (if corrected) could then just be provided as a child waypoint.