[OSM-talk-fr] Trop d'infos tue l'info...

[Philippe Piquer]

Je vois pas tres bien la différence que tu fais entre Said ton épicier d'en
bas , et le restaurant deux maisons plus loin ... deux commerces : meme
layer

Pour le layer de base , bah en gros les
highways,waterways,landuse,natural,railway

Attention j'ai pas dis que l'on ne pouvait pas mettre toutes les infos dans
le meme 'serveur' , c'est juste la carte qui me pose probleme ... pour le
moment c'est un peu comme si tu ouvres Google Earth avec tous les layers
cochés .... et que tu n'as pas la possibilité de décocher quoi que ce soit
... c'est juste stupide ...

Le 28 mai 2008 21:26, Denis <dhelfer at free.fr> a écrit :

> Philippe Piquer a écrit :
> > Pieren disait sur un autre sujet ....
> >
> > --------------------------------
> > On devrais s'en tenir à ce qui décrit le physique même si il y a une
> > tendance naturelle à profiter de la base pour y mettre toujours plus
> > (système ouvert). On a vu le même phénomène sur wikipedia.
> > C'est pourquoi je suis souvent sceptique quand je vois les tags de
> > restaurants, shops, etc... qui tient plus de la cartographie dynamique
> dans
> > une base séparée.
> > --------------------------------
> > Dieu que je suis d'accord avec ca .....
> > Une carte de base physique et des couches multiples pour les POI ....
> > Du coup les couches sont calculées séparément et sont donc plus légères
> et
> > rapides à calculer ...
> >
> > Je sais qu'il y a moyen de faire sa propre base et son propre serveur ,
> et
> > ses propres cartes mais je trouve cela moins efficaces...
> >
> > Philippe
>
> Pas fondamentalement opposé au principe de distinguer des ensembles
> d'objets (des layers ?), surtout si c'est pour + de perf. Reste à
> définir ce qui relève de tel ou tel layer. Ne pas confondre usage et
> description du "réel". La boite aux lettres ou la cabine téléphonique
> font partie du réel, mais sont d'un usage particulier. Ce sont des POI.
> Les limites administratives sont "invisibles" sur le terrain, pourtant
> elles ont une importance considérable pour des extractions ; les limites
> communales "cassent" les dénominations des voies de circulation. Bref
> c'est un composant non négligeable non visible.
> Bref, la distinction n'est pas aussi aisé qu'il y paraît. Oui, je rentre
> dans OSM des boîtes aux lettres, des bureaux de poste, des bennes de
> recyclage, des restaurants, des commerces. Simplement parce qu'ils font
> partie de mon environnement quotidien, parce que je SAIS que localiser
> un point d'après simplement son adresse avec les algorithmes actuels
> reviendrait à ne pas ambitionner de faire mieux que Google, Navteq et
> consort (encore faudrait-il que le "type" de point les intéresse, rentre
> dans leur business model). Mon épicier Saïd en bas de chez moi, je n'ai
> pas besoin de le géolocaliser. Si je l'ai fait, c'est pour les autres.
> Dans le même temps, je n'ai pas non plus indiqué ces horaires
> d'ouverture, ni  mon avis sur sa convivialité et son rôle dans le
> quartier. C'est l'affaire de portails de services communautaires qui
> verront probablement le jour prochainement. Si OSM peut leur proposer
> une géolocalisation qui permet à l'utilisateur final de ne pas se
> retrouver dans le paté de maison d'à côté, j'aurais fait mon office.
> Il reste, j'en conviens, à trouver la limite "raisonnable" dans la
> description du réel. Nous expérimentons chaque jour des nouveaux tags
> (de nouvelles analyses du réel), de nouvelles pratiques, de nouveaux
> débats. Celui-ci me paraît prématuré mais a le mérite de soulever le
> problème de la "scalabilité" du projet OSM (et in fine du financement
> des serveurs offrant les données) : l'expérience Wikipédia peut être
> riche d'enseignements.
> Une analyse serait rigolote : quel pays consomme le plus d'octets dans
> la base ? J'ai l'intuition que nous autres Français ne sommes pas en
> tête du peloton.
>
> Denis
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20080528/540e9b5e/attachment.htm>