[Osmf-talk] OSM API download bug: south east corner of data missing

80n 80n80n at gmail.com
Thu Nov 19 14:18:19 UTC 2009


Graham
I think the only way to overcome this would be to do a series of smaller
requests, unless I lift the limit.

The limit is there to kill silly requests that are trying to download the
whole planet.  It's difficult to achieve a suitable balance.

80n

On Thu, Nov 19, 2009 at 2:05 PM, Graham Asher
<graham.asher at btinternet.com>wrote:

>  You're right - sorry to waste your time. I didn't know about that limit.
> Can it be overcome somehow?
>
> Graham
>
>
> 80n wrote:
>
> Graham
> It's possible that you've hit the 1m element limit on these requests.
>
> Is there any message at the end of each file?
>
> 80n
>
> On Thu, Nov 19, 2009 at 1:40 PM, Graham Asher <graham.asher at btinternet.com
> > wrote:
>
>> I've found a bug in the OSM API v0.6 - is there a bug tracking system I
>> can log it to?
>>
>> Details:
>>
>> <<<<<<
>> The bug is this: when downloading a large amount of data by specifying a
>> rectangular bounding box, quite often the south east corner is missing.
>> Some evidence: note the sizes of downloaded data in the following
>> requests:
>>
>> $ curl
>>
>> http://osmxapi.hypercube.telascience.org/api/0.6/map?bbox=-88.546,41.327,-86.97,42.382
>>  >chicago.osm
>>  % Total    % Received % Xferd  Average Speed   Time    Time     Time
>> Current
>>                                 Dload  Upload   Total   Spent    Left
>> Speed
>> 100  308M    0  308M    0     0   155k      0 --:--:--  0:33:48
>> --:--:--  224k
>>
>> $ curl
>>
>> http://osmxapi.hypercube.telascience.org/api/0.6/map?bbox=-88.427,41.399,-87.105,42.325
>>  >chicago.osm
>>  % Total    % Received % Xferd  Average Speed   Time    Time     Time
>> Current
>>                                 Dload  Upload   Total   Spent    Left
>> Speed
>> 100  311M    0  311M    0     0   144k      0 --:--:--  0:36:42 --:--:--
>> 86062
>>
>> The second request is for a smaller area - an area entirely included in
>> the bounds of the first area, and smaller on every side - yet more data
>> arrives (311M instead of 308M) showing that something is awry.
>>  >>>>>>
>>
>> [I have sent a copy of this message with an illustration, but it is
>> greater than the 40K limit for postings, and awaiting approval. so I am
>> sending a briefer version in the hope of getting a quick response]
>>
>> Graham Asher
>>
>>
>> _______________________________________________
>> osmf-talk mailing list
>> osmf-talk at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/osmf-talk
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20091119/2a8187c0/attachment.html>


More information about the osmf-talk mailing list