One of my "workarounds" was to just take the numbers after the decimal devider and restrict yourself to an area that doesn't cross longitude or latitudes. This sort of works, exept this major limitation. Just now doing a workshop with audio walks in Riga and figured out another limitation.
24.07723 translates to 77238 because a leading zero just gets truncated obviously. outch. It's all possible somehow, but it would be so much easier with double precision.
m.
On 2017년 04월 21일 18:29, hans w. koch wrote:
thank you max,
now i remember you posted this a while ago on the list, right? i had earmarked it and then forgotten... i am aware of the double precision dilemma (also encountered it in mobmuplat). for the purpose of parsing these files from bicycle tours offline, i was hoping to get away ignoring it, but i guess you are right to point it out again :-)
best hans
Am 21.04.2017 um 17:15 schrieb Max abonnements@revolwear.com:
On 2017년 04월 21일 15:40, hans w. koch wrote:
i need to parse lines like this: gx:coord8.689756393432365
next thing you might want to have is double precision in Pd. At least single precision is a major headache when dealing with gpx coordinates in Pd. Maybe some abstractions in there can be useful for you, albeit there are bugs.