[Openstreetmap] How do we handle large amount of GPS points?

[Matt Amos]

On Sunday 21 November 2004 22:45, SteveC wrote:
> * Petter Reinholdtsen (pere at hungry.com) wrote:
> > > Now, my table looks like lat,lon,alt,time,userid
> >
> > My table includes (lat,lon)::point, altitude, quality
> > (0,1=gpx,2=dgps), satellites, and hor. dilution.  I fetch data
> > using the GGA NMEA sentence.
>
> Ok, AFAIR talking to matt we need more than this. We need track
> numbers and stuff to do line extraction, and data for later dgps
> resoving. To clear this up, how does this scheme look where we
> ignore exactly how lat/long is stored (eg two columns or in a Point
> or what).
>
> lat float not null
> long float not null
> alt float not null
> hor_dilution float
> vert_dilution float
> track num bigint
> quality byte
> satellites (type spec for this?)
> timetamp long

why not "datetime"?

> time_dilution int
> uid bigint not null

whats currently giving me a headache, besides c++'s restrictions on 
static constructors, is that a continguous track may become several 
segments of road (in the TIGER meaning - each segment being 
non-overlapping monotonous) and several non-contiguous segments of 
tracks (e.g: if the lock keeps dropping in a city) might be one road 
segment...

the association of roads should be backwards onto the points (i.e: the 
points table is at some level more "basic" than the paths table), but 
that doesn't fit very well with the relational paradigm... you'd end 
up with a paths_segments table which maps points onto paths...

hmmm... maybe thats actually ok...?

cya,

matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20041122/b5273312/attachment.pgp>