--- On Thu, 25/6/09, Andy Owen wrote:
> If HTML was based on JSON, it would be somewhat ugly, and I
> think an
> XMLish like thing suits it well.
Yes, but we're not talking about displaying html, and in fact most people
snubbed xhtml and it virtually doesn't get used at all, so it doesn't seem
On Thu, 2009-06-25 at 05:16 -0700, John Smith wrote:
> JSON offers most of the advantages of XML, without a lot of the drawbacks,
> XML is often referred to as a horse designed by a committee and they ended up
> with a camel :)
>
The way I see it - XML is good for marking up text. JSON is good
--- On Thu, 25/6/09, James Livingston wrote:
> It all comes down to what you want to use the data for. Are
> you
> constantly access it? Occasional access? Archival purposes?
> Read-only
> or are you writing too?
At this stage, I personally, only have one purpose, to collect and upload to
O
--- On Thu, 25/6/09, Liz wrote:
> what about Air France?
They find the black box yet?
___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au
On 25/06/2009, at 8:02 PM, John Smith wrote:
> --- On Thu, 25/6/09, James Livingston wrote:
>> * the DOP has changed
>
> Why would this matter, DOP usually varies, although it is usually
> pointless recording over 4 or 5, and if you want to 1dp multiple it
> by ten, so you only really need +/-
On Thu, 25 Jun 2009, John Smith wrote:
> Most altitude won't change by +/-60m that quick unless you're on a Qantas
> flight :)
what about Air France?
___
Talk-au mailing list
Talk-au@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-au
--- On Thu, 25/6/09, James Livingston wrote:
> Because I'm a bit bored, I thought about the above. Assume
> you want an
> accuracy of 1m and 1s:
Most use 6dp (about 10cm) because it fits neatly in an int, but yea 1m or even
multiples of 2 or 3m might be good enough since most GPS won't do bet
On 25/06/2009, at 6:53 PM, James Livingston wrote:
> If you are that concerned about space, you'd definitely want to use
> some form of delta encoding, and probably variable-length encoding
> too. Why spend a whole four bytes storing the latitude? Presumably
> it's going to be fairly close to
On 24/06/2009, at 12:59 PM, John Smith wrote:
> Also with my previous answer, you can get away with only 14 bytes
> per point rather than 17, 3 bytes for time, 4 for lat, 4 for lon, 2
> for time, 1 for hdop. Although if reset tracks that go over 65,000
> seconds back to zero you could get awa
--- On Tue, 23/6/09, Graeme Wilson wrote:
> Another idea is to have our own proprietry file format
> called .osm I reckon that we could have several lines of
> text at the start to declare things like program version,
> who made the file, the start and end time of the actual
> recording for copyr
--- On Tue, 23/6/09, Sam Couter wrote:
> It's true that XML is very verbose. However all that
> verbosity
> compresses extremely well, so it's not really a significant
> problem.
If you'd had said the cost of hdd space was approaching zero I'd have agreed
with you.
When I was playing around wi
John Smith wrote:
> --- On Tue, 23/6/09, Graeme Wilson wrote:
> > I also think that the GPX file is too verbose with all the
> > XML formatting, and reckon that it will fill up the servers
> > with too much unnecessary stuff. I have been told that for
> > copyright purposes, all the data etc that
--- On Tue, 23/6/09, Graeme Wilson wrote:
> I have ideas about trimming out unnecessary points in GPX
> files. I wrote an elementary program to look at positions,
> and if there were more than two positions the same, then it
> meant that the car was stationary for more than two seconds.
> The pro
For those interested in doing stats against GPX files, the automated uploads I
setup are starting to collect a large number, almost 1000, of GPX files.
The question is, is the information in these traces going to be useful, or just
make noise. If the answer is mostly noise is there any suggesti
14 matches
Mail list logo
