Re: Package description review for CycloGraph
Federico Brega wrote:
>> CycloGraph aims to be great at producing graphically appealing images
>> to document the stages of a race or to be shown on web pages and
>> journals.
>>
>> (If the journals aren't web pages, what are they? Oh well.)
>
> Do you think "newspaper" is a better term, or it's just a
> consideration about the obsolescence of paper?
There's a slight problem in that things can be shown "on" web pages
and blogs and so on (and even individual newspaper pages, covers,
etc.) but only "in" newspapers and (print) journals. Also, the
alternatives aren't exclusive: you might put the images on a web page
in order to document the stages of a race. And if I'm going to have
to fiddle with the phrasing I want it to come out as a proper
three-item list! So how about boiling it down to something like
"images to illustrate course descriptions, training blogs, and race
reports"?
[...]
>> I think this is trying to say:
>>
>> Note that GPS tracking data is usually not enough to produce a
>> high-quality plot because although it contains a lot of points,
>> only a few really add any information to the plot.
>>
>> I don't understand the explanation, but then again I'm not familiar
>> with GPS data.
>
> The idea is that increasing the number of points over a certain
> threshold will add noise instead of information.
> My intention was to avoid the concept of noise which can be unfamiliar
> for many people.
Apparently it's unclear to me, too, because I would have thought the
best way of dealing with noisy data was to use the biggest possible
sample and take the average.
> I think it can be added:
>
> "Using more points would introduce insignificant details, making the
> image less clear"
This may make sense to Christian...
Or is this the altitude resolution problem you mention later? I
wouldn't have said that had anything much to do with "noise" - if it's
that, just say:
Note that GPS tracking data is usually not enough to produce a
high-quality plot because of the resolution limits of its altitude
data.
[...]
>>> CycloGraph embedds a tool to create a kml file by drawing a
[...]
>>> polyline on a map (Open Street Map or Google Maps). The same tool
>>> can also interface to Google Maps' directions.
>>
>> I really don't know what that's supposed to mean. Its directions?
>
> can also interface to Google Maps' "get directions" service.
> Do you think it is clear?
Good, but I'd also avoid trying to possessivise "Google Maps":
can also interface to the Google Maps "get directions" service.
>>> [...] On the other hand, if
>>> they are too close the slope may be very inaccurate due to the
>>> resolution of the altitude data.
[...]
>> How does that work, anyway? Surely it's not saying that the road
>> surface is a fractal and therefore gets longer and longer the more
>> accurately you measure it...
>
> If the distance between two points is less than the sample dimension
> the plot looks like a staircase function.
And a staircase function looks like a staircase!
> In addition to that the derivative is very inaccurate ranging from 0
> to some very high value.
Okay, so the problem isn't that extra points make it less accurate;
it's just that they only give an increasingly accurate picture of the
limitations of the GPS data. So how about:
On the other hand, no matter how close together they are, the slope
will only be as accurate as the resolution of the altitude data.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: