On 28/07/09 14:21, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jul 28, 2009 at 11:15 AM, Tom Hughes<[email protected]> wrote: >> On 28/07/09 11:33, Ævar Arnfjörð Bjarmason wrote: >>> Implementing this would require new tables in the database, optional >>> changes to all editors (since they could keep using /trackpoints), and >>> new database tables to track GPX data and its history. >> Does it really need any new tables? I can't see why, unless you really want >> to pull track segments out into a separate table? What would be in there >> though other that the track ID and track segment ID - does a GPX file >> contain any information other than that about a segment? > > GPX supports arbitrary tags. If we were to import that losslessly& > serve it to users via an API we'd need more than just the current > gps_points table (which only allows for a small subset of possible > tags). > > To support arbitrary GPS tags we'd need gps_points and gps_point_tags > (modeled after node_tags). So that e.g. gps_points.altitude would be > removed and replaced by gps_point_tags.k = ele.
Erk... We're trying NOT to need 10 times more space than now... > Track segments could then be done by reusing the schema for > current_ways/way_tags. And if editing was to be supported > corresponding history tables would need to be created as well. > >> Waypoints is the other things I guess. I have considered adding them in the >> past but never quite got around to it. There was a historic argument against >> adding them but I think that can largely be ignored to be honest. >> >>> How does this sound? I'm pretty happy with the 0.6 API except for the >>> GPS bits. I'd like to make GPX a first-class object in OSM and would >>> be willing to hack the rails port to make that happen (when I have >>> time). Is anyone else interested in being able to do what I've >>> described above? >> The API code is the easy bit - the performance and disk space issues will be >> the hard problems to solve. > > The majority of space imported GPX traces take up is in their track > point. Most GPS loggers seem to log only lat/lon/ele/time so we > wouldn't be storing anything additionally there. Except that you just transformed a four byte elevation into three characters of "ele" key plus N bytes of text for the actual elevation by moving all the elevations to a tag table. Tom -- Tom Hughes ([email protected]) http://www.compton.nu/ _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
