[OSM-talk-fr] OpenStreetBugs

[X]

> un numéro unique comme pour les bugtrackers avec une url qui pointe
>  dessus permettrait de suivre un bug

Ah oui. Indispensable....
Au même titre que pouvoir spécifier des coordonnées dans l'URL afin de
ne pas tomber à chaque fois sur la magnifique ville de Rennes :-)

> Je veux rapporter une erreur concernant un [bâtiment/rue/nom/point 
> d'intérêt/zone/autre(précisez)]

J'y ai réfléchi, mais est-ce vraiment utile ? Quid des
doubles-classifications ? Peut-on être exhaustif ? Faut-il une
hiérarchisation ? etc.
Un système de tags... avec toutes les discussions passionnantes que ça
engendre ;-)

Trop formaliser tue la créativité.

> Faire apparaître les FIXME/TODO me paraît indispensable

J'ai pas compris.

> Le bouton pour ajouter un report ne saute pas assez aux yeux

Oui. J'en sue avec le placement de ce bouton. Je n'ai pas d'idée miracle.

> FF3RC1 (Kubuntu - KDE4.1b) ne fonctionne pas , ni sous Konqueror
> KDE4

Si ça ne fonctionne pas sur FF3 c'est particulièrement gênant, sachant
que dans 5 jours, 90% de la population d'OSM tournera dessus ;-)

> Je ne trouve pas le lien avec GoogleAppEngine ou alors c'est au 
> niveau du serveur

Oui.
GoogleAppEngine est :
- un hébergement limité mais gratuit
- un framework original (Python + BigTable)
Donc, côté utilisateur, que ce soit là dessus où sur un LAMP classique,
ça ne
change rien.

> le côté "pas d'authentification" me chagrinne.

Ma philosophie c'est :
- OSM = données clean = authentification
- OpenStreetBugs = données brouillon = pas d'authentification
Ça ne sert à rien de faire un truc sécurisé et complexe si c'est pour
faire moins bien que Potlatch.

Et pour te rassurer un peu...
1. OSB est indélébile. Ce qui y est écrit reste tel quel. Par contre il
est possible pour n'importe qui d'ajouter autant de compléments
d'information que nécessaire.
2. Pour l'instant, aucune donnée n'est réellement supprimée (quand vous
faites "del", les données deviennent justes inaccessibles). Il est donc
techniquement possible de récupérer les données perdues. Je
dis "pour l'instant", car GoogleAppEngine (version gratuite) limite la
base de données à 500Mo...

> tu devrait presenter l'url sur la liste anglaise.

Oui.
Je vais peut-être corriger un ou deux bugs avant.

>> La base de données, c'est BigTable
> ça me donne envie de m'y mettre aussi

Si tu aimes les tables de hachage, les listes chaînées, les arbres
binaires... c'est chouette.

> Il y a tout de même un problème, qui n'apparait pas pour l'instant
> vu le faible nombre de POIs, mais qui ne tardera pas à pointer le
> bout de son nez dès que leur nombre sera conséquent (qqs centaines)
> : tous sont chargés au démarrage de l'application.

Non.
Seuls les points visibles sont chargés ; les autres sont chargés en AJAX
au fur et à mesure qu'on fait glisser la carte.

Lorsqu'on dézoome trop, les points ne sont pas non plus chargés (ceux
qu'on voit sont ceux qui ont déjà été chargés).

> Ce qui risque de ralentir bcp leur chargement à terme. Un remède : 
> n'afficher que ceux qui sont présents dans l'étendue courante de la
>  carte et limiter ce nombre à 100 (par exemple).

J'ai déjà limité (120 pois max par requête).

Par contre je n'ai pas fait de garbage collector : une fois les points
chargés, ils sont chargés. Donc s'il on joue trop longtemps avec OSB, ça
risque de ramer.

>> Yaurai moyen d'avoir le code source ? ou d'ajouter des
>> développeurs sur le projet AppEngine ?
> Je plussoie la demande ;-)

J'y pense :-)
Mais le code n'a rien de spectaculaire et n'est pas super clean.
- 90% du code est côté client (script.js)
- 10% du code est côté serveur (python)

Xav