Re: [OSM-talk-fr] Trop d'infos tue l'info...
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...
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/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...
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...
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/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...
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...
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...
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...
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...
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
[OSM-talk-fr] Trop d'infos tue l'info...
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
Re: [OSM-talk-fr] Trop d'infos tue l'info...
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
Re: [OSM-talk-fr] Trop d'infos tue l'info...
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
