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

2008-05-29 Par sujet Raphaël Jacquot
Denis wrote:
> Pieren a écrit :
>> 2008/5/29 Renaud Martinet <[EMAIL PROTECTED]>:
>>
>>> Mais il me semble qu'il y a déjà des gens qui bossent sur
>>> un format binaire notamment pour tout ce qui est PDA
>>>
>> Il y a effectivement un format binaire en discussion  (
>> http://wiki.openstreetmap.org/index.php/OSM_Mobile_Binary_Protocol) mais il
>> présente l'énorme inconvénient de figer les données dans un format prédéfini
>> qui sera bien moins flexible que le système actuel (
>> http://wiki.openstreetmap.org/index.php/OSM_Mobile_Binary_Protocol/Feature_Tags
>> ).
>>
>> La solution vient plutôt de la généralisation de l'utilisation continue des
>> fichiers XML compressés (bz2) en utilisant des API accédant aux données XML
>> sans passer par une phase de décompression externe dans tous les logiciels
>> (ce que font déjà certains scripts/programmes).
>>
>> Pieren
> 
> Pour moi, La question n'est pas : XML vs binaire. L'OGC a bien défini le 
> GML (Geographic Markup Language) comme pierre angulaire de ses normes et 
> c'est un dialecte XML. Bz2 compresse très bien les gros volumes (mais, 
> inversement, consomme de la ressource pour décompresser).
> Si la base OSM pouvait cracher du GML, on aurait fait un pas en avant. 
> Si un programme standard (style SIG bureautique) pouvait causer avec la 
> base OSM en parlant WFS ou même WMS, il arrêterai de pleuvoir des 
> scripts de conversion de tout poil.
> 
> Je comprend bien la motivation initale d'avoir un produit qui tourne 
> rapidement (j'ai suffisamment bossé sur ces satanées spécifications OGC 
> pour savoir qu'elles ne sont pas triviales).
> Je reste persuadé qu'il y a une niche pour "wrapper" le contenu de la 
> base dans une interface standard que beaucoup de clients potentiels 
> pourraient utiliser.
> Je réfléchis à voix haute... trop tard...trop lentement
> Denis

ni l'un ni l'autre n'a compris l'intéret du truc...
alors je reprends ;)

ce format binaire serait fait pour les appareils mobiles qui n'ont que 
tres peu de ressources processeur, et peu de mémoire. souvent, ca ne 
sait pas faire de calculs en virgule flottante non plus.

un format comme du xml compressé en bz2 est alors proscrit. un format 
binaire proprement indexé, avec des zones carrées, permet d'etre 
efficace sur ce type de plateforme.

de maniere similaire, on pourrait utiliser le garmin .img
mais celui ci est plus limité.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-29 Par sujet Denis
Pieren a écrit :
> 2008/5/29 Renaud Martinet <[EMAIL PROTECTED]>:
> 
>> Mais il me semble qu'il y a déjà des gens qui bossent sur
>> un format binaire notamment pour tout ce qui est PDA
>>
> 
> Il y a effectivement un format binaire en discussion  (
> http://wiki.openstreetmap.org/index.php/OSM_Mobile_Binary_Protocol) mais il
> présente l'énorme inconvénient de figer les données dans un format prédéfini
> qui sera bien moins flexible que le système actuel (
> http://wiki.openstreetmap.org/index.php/OSM_Mobile_Binary_Protocol/Feature_Tags
> ).
> 
> La solution vient plutôt de la généralisation de l'utilisation continue des
> fichiers XML compressés (bz2) en utilisant des API accédant aux données XML
> sans passer par une phase de décompression externe dans tous les logiciels
> (ce que font déjà certains scripts/programmes).
> 
> Pieren

Pour moi, La question n'est pas : XML vs binaire. L'OGC a bien défini le 
GML (Geographic Markup Language) comme pierre angulaire de ses normes et 
c'est un dialecte XML. Bz2 compresse très bien les gros volumes (mais, 
inversement, consomme de la ressource pour décompresser).
Si la base OSM pouvait cracher du GML, on aurait fait un pas en avant. 
Si un programme standard (style SIG bureautique) pouvait causer avec la 
base OSM en parlant WFS ou même WMS, il arrêterai de pleuvoir des 
scripts de conversion de tout poil.

Je comprend bien la motivation initale d'avoir un produit qui tourne 
rapidement (j'ai suffisamment bossé sur ces satanées spécifications OGC 
pour savoir qu'elles ne sont pas triviales).
Je reste persuadé qu'il y a une niche pour "wrapper" le contenu de la 
base dans une interface standard que beaucoup de clients potentiels 
pourraient utiliser.
Je réfléchis à voix haute... trop tard...trop lentement
Denis

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-29 Par sujet Pieren
2008/5/29 Renaud Martinet <[EMAIL PROTECTED]>:

> Mais il me semble qu'il y a déjà des gens qui bossent sur
> un format binaire notamment pour tout ce qui est PDA
>

Il y a effectivement un format binaire en discussion  (
http://wiki.openstreetmap.org/index.php/OSM_Mobile_Binary_Protocol) mais il
présente l'énorme inconvénient de figer les données dans un format prédéfini
qui sera bien moins flexible que le système actuel (
http://wiki.openstreetmap.org/index.php/OSM_Mobile_Binary_Protocol/Feature_Tags
).

La solution vient plutôt de la généralisation de l'utilisation continue des
fichiers XML compressés (bz2) en utilisant des API accédant aux données XML
sans passer par une phase de décompression externe dans tous les logiciels
(ce que font déjà certains scripts/programmes).

Pieren
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-29 Par sujet Renaud Martinet
Les formats OGC n'ont pas été utilisés car SteveC a préféré commencé à
coder et faire en sorte que le projet puisse démarrer rapidement
plutôt que de se taper les specs OGC. Bref il a mis en place le
minimum pour que ça marche en se disnt qu'on améliorerait si besoin.
Il est vrai par contre que le format XML est pratique pour échanger
des petits fichiers mais devient de plus en plus encombrants pour les
gros dumps. Mais il me semble qu'il y a déjà des gens qui bossent sur
un format binaire notamment pour tout ce qui est PDA mais je peux me
tromper.


Renaud.



2008/5/28 Pierre Mauduit <[EMAIL PROTECTED]>:
> Salut,
>
>> Une chose que je n'ai jamais complètement compris : pourquoi avoir
>> renoncé aux modèles de stockage, de diffusion préconisés par l'Open GIS
>> Consortium et qui sont en train de prendre une importance incontournable
>> dans les infrastructures de dissémination de l'information géographique ?
>> La solution passe peut-être par le développement de passerelles qui
>> offriraient des Web Services OGC (Web Feature Service en particulier)
>> aux différents clients ? Après tout, il existe déjà des scripts pour
>> stocker dans PostGIS (implémentation SQL OGC) des données OSM. Des idées
>> pour API (0.7 ou 1.0) ? C'est peut-être déjà en cours de discussions sur
>> ML anglaise, mais vu l'activité de la française, pas le temps de la lire.
>
> Jamais compris non plus ; un dump (binaire ca doit pouvoir se faire avec
> postgre) d'une base de données prendrait surement moins de place qu'un
> énorme fichier xml de plus de 90 Go b2-unzippé. Si quelqu'un a la
> réponse, ca m'intéresse :-)
>
> (pour info le dernier hexagone osm pese 469 Mo, une fois l'import en
> pgsql, la base pèse en terme de fichiers 140 Mo)
>
> Bonne nuit,
>
> --
> Pierre
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-29 Par sujet Pierre Mauduit
Salut,

> Une chose que je n'ai jamais complètement compris : pourquoi avoir 
> renoncé aux modèles de stockage, de diffusion préconisés par l'Open GIS 
> Consortium et qui sont en train de prendre une importance incontournable 
> dans les infrastructures de dissémination de l'information géographique ?
> La solution passe peut-être par le développement de passerelles qui 
> offriraient des Web Services OGC (Web Feature Service en particulier) 
> aux différents clients ? Après tout, il existe déjà des scripts pour 
> stocker dans PostGIS (implémentation SQL OGC) des données OSM. Des idées 
> pour API (0.7 ou 1.0) ? C'est peut-être déjà en cours de discussions sur 
> ML anglaise, mais vu l'activité de la française, pas le temps de la lire.

Jamais compris non plus ; un dump (binaire ca doit pouvoir se faire avec
postgre) d'une base de données prendrait surement moins de place qu'un
énorme fichier xml de plus de 90 Go b2-unzippé. Si quelqu'un a la
réponse, ca m'intéresse :-)

(pour info le dernier hexagone osm pese 469 Mo, une fois l'import en
pgsql, la base pèse en terme de fichiers 140 Mo)

Bonne nuit,

-- 
Pierre


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet Denis
Renaud Martinet a écrit :
> Quand je parle de layers, ce n'est pas uniquement pour l'utilisateur
> final mais également pour nous autres contributeurs. Il serait ma foi
> assez pratique de pouvoir facilement avoir tous les landuses dans un
> layer de josm afin de les modifier sans trop se soucier du reste
> (après on peut bien sûr discuter de si c'est faisable ou pas).
> La plupart du temps l'utilisateur final aura en face de lui une carte
> préparée pour résoudre le problème qui se pose à lui et donc pas
> forcément à plusieurs layers.
> 
> 
> Renaud.

Un équivalent d'une vue dans une base de données ? On reste dans 
l'implémentation de clients (pas seulement finals), à mon avis.
Une chose que je n'ai jamais complètement compris : pourquoi avoir 
renoncé aux modèles de stockage, de diffusion préconisés par l'Open GIS 
Consortium et qui sont en train de prendre une importance incontournable 
dans les infrastructures de dissémination de l'information géographique ?
La solution passe peut-être par le développement de passerelles qui 
offriraient des Web Services OGC (Web Feature Service en particulier) 
aux différents clients ? Après tout, il existe déjà des scripts pour 
stocker dans PostGIS (implémentation SQL OGC) des données OSM. Des idées 
pour API (0.7 ou 1.0) ? C'est peut-être déjà en cours de discussions sur 
ML anglaise, mais vu l'activité de la française, pas le temps de la lire.

Bonne nuit,

Denis

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet Renaud Martinet
Quand je parle de layers, ce n'est pas uniquement pour l'utilisateur
final mais également pour nous autres contributeurs. Il serait ma foi
assez pratique de pouvoir facilement avoir tous les landuses dans un
layer de josm afin de les modifier sans trop se soucier du reste
(après on peut bien sûr discuter de si c'est faisable ou pas).
La plupart du temps l'utilisateur final aura en face de lui une carte
préparée pour résoudre le problème qui se pose à lui et donc pas
forcément à plusieurs layers.


Renaud.



2008/5/28 Denis <[EMAIL PROTECTED]>:
> Philippe Piquer a écrit :
>> 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
>
> Sauf que pour aller chez "mon" Saïd, j'ai juste la rue à traverser pour
> y aller. Même bourré, j'y arrive. Le "coin du Berger", autre commerce de
> quartier, est au coin de quelle rue déjà ?
> Ils sont de même nature, ils exigent une même précision de localisation
> (en gros, juste là où ils sont réellement). Je dis juste que mes
> expériences (comprendre mes analyses de bases professionnelles coûtant
> bonbon) m'incitent à positionner un point d'intérêt local dans OSM
> correctement au lieu de me baser sur un algorithme qui calculerait une
> position plausible en fonction de l'adresse (et d'indications de début
> et fin de n° de rue pour tous les troncons de voirie). L'IGN et sa BD
> Adresse (pour ne pas les nommer) est lamentable sur ce point. Mais on
> n'est pas là pour critiquer la mauvaise utilisation de l'argent public.
> Pour s'en convaincre, il suffit de consulter les nouveaux portails
> contributifs comme dismoisou qui s'appuient sur des bases de POI
> achetées. Chacun a le loisir et la liberté d'aller contribuer sur ce
> genre de sites. Personnellement, je continue sur OSM quitte à réinventer
> sans cesse mon quartier.
>
>>
>> Pour le layer de base , bah en gros les
>> highways,waterways,landuse,natural,railway
>
> Oui des routes, des rivières, des voies ferrées mais pour aller où, pour
> faire quoi ? Il ne faut pas avoir une approche trop topographique sous
> pein de (re)créer des données qui n'auront que pour principale vocation
> de (re)dessiner de nouveaux Top25. Ne perdons pas de vue les
> utilisations (besoins) du citoyen : sur mon téléphone portable (GPSisé),
> il est 22h et j'ai besoin de passer un coup de fil (normal, ma batterie
> va tomber en rade dans 2 mn ;-) : où est la cabine téléphonique la plus
> proche ?
> Bon d'accord, l'exemple est pourri : j'ai même pas de téléphone portable
> (si si !) mais il se fait tard
>
>>
>> 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 ...
> C'est donc un problème de ressources, pas un problème de structuration
> des données. Je crois plus à une répartition des ressources serveurs
> qu'à une répartition des couches (du moins pour le moment) qui ne soit
> pas assise sur une réflexion ontologique (quels sont les objets qui
> composent le réel et quelles sont les relations qui les unissent).
>
> Denis
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet Denis
Philippe Piquer a écrit :
> 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

Sauf que pour aller chez "mon" Saïd, j'ai juste la rue à traverser pour 
y aller. Même bourré, j'y arrive. Le "coin du Berger", autre commerce de 
quartier, est au coin de quelle rue déjà ?
Ils sont de même nature, ils exigent une même précision de localisation 
(en gros, juste là où ils sont réellement). Je dis juste que mes 
expériences (comprendre mes analyses de bases professionnelles coûtant 
bonbon) m'incitent à positionner un point d'intérêt local dans OSM 
correctement au lieu de me baser sur un algorithme qui calculerait une 
position plausible en fonction de l'adresse (et d'indications de début 
et fin de n° de rue pour tous les troncons de voirie). L'IGN et sa BD 
Adresse (pour ne pas les nommer) est lamentable sur ce point. Mais on 
n'est pas là pour critiquer la mauvaise utilisation de l'argent public.
Pour s'en convaincre, il suffit de consulter les nouveaux portails 
contributifs comme dismoisou qui s'appuient sur des bases de POI 
achetées. Chacun a le loisir et la liberté d'aller contribuer sur ce 
genre de sites. Personnellement, je continue sur OSM quitte à réinventer 
sans cesse mon quartier.

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

Oui des routes, des rivières, des voies ferrées mais pour aller où, pour 
faire quoi ? Il ne faut pas avoir une approche trop topographique sous 
pein de (re)créer des données qui n'auront que pour principale vocation 
de (re)dessiner de nouveaux Top25. Ne perdons pas de vue les 
utilisations (besoins) du citoyen : sur mon téléphone portable (GPSisé), 
il est 22h et j'ai besoin de passer un coup de fil (normal, ma batterie 
va tomber en rade dans 2 mn ;-) : où est la cabine téléphonique la plus 
proche ?
Bon d'accord, l'exemple est pourri : j'ai même pas de téléphone portable 
(si si !) mais il se fait tard

> 
> 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 ...
C'est donc un problème de ressources, pas un problème de structuration 
des données. Je crois plus à une répartition des ressources serveurs 
qu'à une répartition des couches (du moins pour le moment) qui ne soit 
pas assise sur une réflexion ontologique (quels sont les objets qui 
composent le réel et quelles sont les relations qui les unissent).

Denis

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet 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 <[EMAIL PROTECTED]> 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@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet Denis
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@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet Bernard VALTON
Je vois que tout est prévu :)

Merci et désolé d'avoir cassé la discussion  ...

bernard

2008/5/28 Pieren <[EMAIL PROTECTED]>:

>
>
> 2008/5/28 Bernard VALTON <[EMAIL PROTECTED]>:
>
>> Bonjour,
>>
>> Est ce qu'il existe un moyen simple de faire une page web mettant OSM en
>> background et rajoutant des layers par dessus. Je pense aux trajets de bus
>> ou de pedibus par exemple. A l'image de ce qui est fait sur mymaps de google
>> maps ?
>>
>
>
> Tu aurais du changer le titre de ton message pour créer un nouveau fil,
> mais bon... trop tard.
> Va voir aussi sur le wiki:
> http://wiki.openstreetmap.org/index.php/Openlayers_POI_layer_example
>
> et surtout
>
> http://wiki.openstreetmap.org/index.php/OpenLayers
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>


-- 
bernard
http://blog.valton.name/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet Pieren
2008/5/28 Bernard VALTON <[EMAIL PROTECTED]>:

> Bonjour,
>
> Est ce qu'il existe un moyen simple de faire une page web mettant OSM en
> background et rajoutant des layers par dessus. Je pense aux trajets de bus
> ou de pedibus par exemple. A l'image de ce qui est fait sur mymaps de google
> maps ?
>


Tu aurais du changer le titre de ton message pour créer un nouveau fil, mais
bon... trop tard.
Va voir aussi sur le wiki:
http://wiki.openstreetmap.org/index.php/Openlayers_POI_layer_example

et surtout

http://wiki.openstreetmap.org/index.php/OpenLayers

Pieren
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet Philippe Piquer
Oui et non 

Pour mettre OSM sur un site , voir OpenLayers(.org) qui permet de mettre une
seule 'carte' avec de multiple couche (transparente ou pas).
Evidemment pour remplir une couche , il faut aussi une carte et donc créer
un serveur qui s'occupe du rendu de cette carte...
Par contre rajouter des POI est assez simple ...

Sur la page d'acceuil de http://www.lessines.net , il y a la carte OSM de la
ville avec trois couches : osmarender, mapnik et Cyclemap, mais ce que je
trouve dommage c'est par exemple que la couche cycle reprends de facon
redondante (meme si légèrement modifiée) la carte de base et est opaque...

Philippe

2008/5/28 Bernard VALTON <[EMAIL PROTECTED]>:

> Bonjour,
>
> Est ce qu'il existe un moyen simple de faire une page web mettant OSM en
> background et rajoutant des layers par dessus. Je pense aux trajets de bus
> ou de pedibus par exemple. A l'image de ce qui est fait sur mymaps de google
> maps ?
>
> Cordialement
> Bernard
>
> 2008/5/28 Philippe Piquer <[EMAIL PROTECTED]>:
>
> C'est bien comme cela que je rajoute les commerces de ma commune à Google
>> Maps sur mon site (devrait etre remplacé par OSM dès que les 5% non encore
>> mappés le seront).
>>
>> Le 28 mai 2008 09:41, David MENTRE <[EMAIL PROTECTED]> a écrit :
>>
>> Bonjour,
>>>
>>> Le 27 mai 2008 23:09, Julien Langlois <[EMAIL PROTECTED]> a
>>> écrit :
>>> > il faut quand même trouver un moyen de relier ces POI
>>> > (d'une base externe) avec une adresse dans OSM pour qu'il soit
>>> > possible dans un logiciel de routage avancé de demander le nom d'un
>>> > restaurant au lieu de son adresse.
>>>
>>> Ce lien, est-ce que ce n'est pas les coordonnées géographiques
>>> (latitude, longitude) ?
>>>
>>> Je cherche un restaurant :
>>>  1. base externe, nom restau -> coordonnées (dest_lat, dest_lon) ;
>>>
>>>  2. GPS, -> (source_lat, source_lon) ;
>>>
>>>  3. OSM, recherche des points source et destination voisins dans OSM
>>> et routage avec les routes, type de route, type de véhicule, etc. en
>>> fonction des infos OSM.
>>>
>>> Amicalement,
>>> d.
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>>
>>
>
>
> --
> bernard
> http://blog.valton.name/
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet Bernard VALTON
Bonjour,

Est ce qu'il existe un moyen simple de faire une page web mettant OSM en
background et rajoutant des layers par dessus. Je pense aux trajets de bus
ou de pedibus par exemple. A l'image de ce qui est fait sur mymaps de google
maps ?

Cordialement
Bernard

2008/5/28 Philippe Piquer <[EMAIL PROTECTED]>:

> C'est bien comme cela que je rajoute les commerces de ma commune à Google
> Maps sur mon site (devrait etre remplacé par OSM dès que les 5% non encore
> mappés le seront).
>
> Le 28 mai 2008 09:41, David MENTRE <[EMAIL PROTECTED]> a écrit :
>
> Bonjour,
>>
>> Le 27 mai 2008 23:09, Julien Langlois <[EMAIL PROTECTED]> a écrit
>> :
>> > il faut quand même trouver un moyen de relier ces POI
>> > (d'une base externe) avec une adresse dans OSM pour qu'il soit
>> > possible dans un logiciel de routage avancé de demander le nom d'un
>> > restaurant au lieu de son adresse.
>>
>> Ce lien, est-ce que ce n'est pas les coordonnées géographiques
>> (latitude, longitude) ?
>>
>> Je cherche un restaurant :
>>  1. base externe, nom restau -> coordonnées (dest_lat, dest_lon) ;
>>
>>  2. GPS, -> (source_lat, source_lon) ;
>>
>>  3. OSM, recherche des points source et destination voisins dans OSM
>> et routage avec les routes, type de route, type de véhicule, etc. en
>> fonction des infos OSM.
>>
>> Amicalement,
>> d.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>


-- 
bernard
http://blog.valton.name/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet Philippe Piquer
C'est bien comme cela que je rajoute les commerces de ma commune à Google
Maps sur mon site (devrait etre remplacé par OSM dès que les 5% non encore
mappés le seront).

Le 28 mai 2008 09:41, David MENTRE <[EMAIL PROTECTED]> a écrit :

> Bonjour,
>
> Le 27 mai 2008 23:09, Julien Langlois <[EMAIL PROTECTED]> a écrit
> :
> > il faut quand même trouver un moyen de relier ces POI
> > (d'une base externe) avec une adresse dans OSM pour qu'il soit
> > possible dans un logiciel de routage avancé de demander le nom d'un
> > restaurant au lieu de son adresse.
>
> Ce lien, est-ce que ce n'est pas les coordonnées géographiques
> (latitude, longitude) ?
>
> Je cherche un restaurant :
>  1. base externe, nom restau -> coordonnées (dest_lat, dest_lon) ;
>
>  2. GPS, -> (source_lat, source_lon) ;
>
>  3. OSM, recherche des points source et destination voisins dans OSM
> et routage avec les routes, type de route, type de véhicule, etc. en
> fonction des infos OSM.
>
> Amicalement,
> d.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-28 Par sujet David MENTRE
Bonjour,

Le 27 mai 2008 23:09, Julien Langlois <[EMAIL PROTECTED]> a écrit :
> il faut quand même trouver un moyen de relier ces POI
> (d'une base externe) avec une adresse dans OSM pour qu'il soit
> possible dans un logiciel de routage avancé de demander le nom d'un
> restaurant au lieu de son adresse.

Ce lien, est-ce que ce n'est pas les coordonnées géographiques
(latitude, longitude) ?

Je cherche un restaurant :
 1. base externe, nom restau -> coordonnées (dest_lat, dest_lon) ;

 2. GPS, -> (source_lat, source_lon) ;

 3. OSM, recherche des points source et destination voisins dans OSM
et routage avec les routes, type de route, type de véhicule, etc. en
fonction des infos OSM.

Amicalement,
d.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-27 Par sujet Julien Langlois
Je suis d'accord avec ça aussi. Par exemple, stocker la population
d'une ville dans OSM n'a aucun intérêt puisque la commune est
identifié par son code INSEE et qu'il est donc très facile de faire un
requête sur une base qui sera potentiellement plus complète et à jour.

Par contre, il ne faut pas enlever la nature géographique d'un POI. En
effet, même s'il n'est pas "normal" de tagger tous les commerce dans
la base OSM, il faut quand même trouver un moyen de relier ces POI
(d'une base externe) avec une adresse dans OSM pour qu'il soit
possible dans un logiciel de routage avancé de demander le nom d'un
restaurant au lieu de son adresse. Mais là, on mélange peut être
annuaire et routage :
 * je veux aller chez machin
 * adresse = annuaire(machin)
 * routage(adresse) --> partie OSM
Cependant, le fait d'utiliser cet "annuaire" est une sorte de lien
entre le POI et l'élément OSM.

Bref, je pense que ce n'est pas dans la base OSM qu'il faut stocker
tous ces POI mais qu'il nous faut prendre garde à ce que la base soit
assez "standard" pour qu'un soft/moteur de rendu/... puisse relier ces
informations

-- 
 Julien
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr


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

2008-05-27 Par sujet Renaud Martinet
Je pense qu'on en viendra à un moment à avoir plusieurs layers
peut-être même dans la base de données elle-même je ne sais pas.. mais
tout ce qui est landuse par exemple ne demande qu'à être mis dans un
layer à part.


Renaud.



2008/5/27 Philippe Piquer <[EMAIL PROTECTED]>:
> 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
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
>
>

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr