[OSM-dev] Basic GPX parser in OpenLayers

Shaun McDonald shaun at shaunmcdonald.me.uk
Thu Oct 18 19:11:57 BST 2007

On 18 Oct 2007, at 16:44, Christopher Schmidt wrote:

> On Thu, Oct 18, 2007 at 04:49:06PM +0200, Joerg Ostertag (OSM  
> Munich/Germany) wrote:
>> On Donnerstag 18 Oktober 2007, Christopher Schmidt wrote:
>>> On Thu, Oct 18, 2007 at 03:08:48PM +0100, Tom Hughes wrote:
>>>> In message <20071018135805.GA18708 at metacarta.com>
>>>>         Christopher Schmidt <crschmidt at metacarta.com> wrote:
>>>>> Note that parsing Very Large data could take awhile -- I don't  
>>>>> know how
>>>>> long of tracks people typically upload. The 1000 point track  
>>>>> from my
>>>>> commute this morning was ~200kb -- but my GPS recording client  
>>>>> is kinda
>>>>> verbose.
>>>>> Anyone have some examples of how big a 'large' gpx file usually  
>>>>> is for
>>>>> them that I can try out for performance?
>>>> Well http://www.openstreetmap.org/user/TomH/traces/43998 is a 26  
>>>> mile
>>>> cycle trace from last weekend - about 3.5 hours worth.
>>> Okay. That one is a bit long :) Not unbearably so. I'll take that  
>>> as a
>>> target and see if I can improve performance to the extent that  
>>> load time
>>> is tenable.
>> Last time I tested the max size of GPX accepted by the osm-server  
>> was 5MB
>> compressed. Just for Info.
> Yeah, there's no way that OpenLayers is going to support drawing a GPX
> file that big -- even assuming I can figure out how to make the  
> browser
> load the .gz compressed data properly, it's still going to be ~50mb of
> uncompressed data (if tom's 300k -> 3MB is any standard  
> comparison), and
> that's not going to be doable.

That is a fairly common compression ratio in my experience. Sometimes  
I'm getting an even better compression, depending on where I've been  
and the type of route/traffic.

> Since the point counts are available in the GPX tracklog page (it
> seems), hopefully we can at least stick it in there for GPX tracklogs
> with less than some number of points -- 1000 is ~2s to render, whereas
> 12000 was 90s, so if I do some speed improvements on it, maybe ew can
> have support for 1000-5000 points or so.

How about using gpsbabel to reduce the point count? In many instances  
you just want to see roughly where the track went, so if it is  
reduced to 1000 points, then in many use cases it could still be useful.


Shaun McDonald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2433 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20071018/139d7f4d/attachment.bin>

More information about the dev mailing list