maposmatic-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Maposmatic-dev] Implementing bbox limitation


From: Maxime Petazzoni
Subject: Re: [Maposmatic-dev] Implementing bbox limitation
Date: Tue, 8 Sep 2009 08:39:12 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Hi,

* Thomas Petazzoni <address@hidden> [2009-09-08 08:28:25]:

> [ The list configuration is really strange: as soon as you're sending
>   me e-mails directly + Cc: to the list, it seems I only receive them
>   directly, and not through the list anymore. Is it a configuration
>   mistake on my side ? More generally, it'd be better if we could avoid
>   Cc'ing all the people that are subscribed to the list. ]

This is actually a feature from the mailing-list system I think. If one
of the list subscribers is also in the To: or Cc: field, it assumes the
email has already been received (a probably more quickly than through
the list) and thus doesn't deliver the message to these persons.

But you're right, we should all be using Reply-to-List (L in mutt),
and avoiding Cc-ing people that are on the list.

> David Decotigny <address@hidden> a écrit :
> 
> > Well, I was thinking about yet another solution. Something like:
> > http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/ocitysmap/coords.py#n66
> 
> Hum, yes, right, we can put a limit of a distance in both ways. That
> would be similar to what I wanted to do.

For the bounding box limit, I think we should simply put a limit on both
directions. We can put a large number here, like 50x50km, which is
probably enough for any city out there, maybe even NYC. We just want to
avoid people trying to render a whole country or the entire planet.

Of course, if rendering 50x50km takes an hour, we can lower this limit
to something more reasonable. But you get the idea, we don't care about
fine tuning this, we just need a "good enough" setting.

In the future, we may also want to order requests by the area of the
bounding box. The smaller, the higher the priority. But every time a
new request goes before an existing one, the priority of the existing
reequest is incremented, to make sure it gets rendered (ol' ol'
schedulin').

- Maxime

-- 
Maxime Petazzoni <http://www.bulix.org>
 ``One by one, the penguins took away my sanity.''
Linux kernel and software developer at MontaVista Software

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]