[OSM-dev] [OSM-talk] Thoughts on an enhanced GPX api

[Tom Hughes]

On 28/07/09 14:21, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Jul 28, 2009 at 11:15 AM, Tom Hughes<tom at compton.nu>  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 (tom at compton.nu)
http://www.compton.nu/