Re: [OSM-talk-fr] Espaces demi m....
Ton TL;DR : (1) les préférences de taille d'affichage de texte (pour l'accessibilité) ne t'intéressent pas ? C'est pourtant essentiel dans les OS et les navigateurs. JOSM n'est pas à la page dessus. Les plus de 40 ans (et d'autres avec des difficultés visuelles plus précoces) remercieront les développeurs de JOSM. Tout le monde devient presbyte, la presbytie commence dès passé les 20 ans mais devient une vraie gêne pour la lecture sur écran vers la quarantaine (même avec une correction optique qui n'est pas idéale non plus). (2) le réglage des polices par défaut ne t'intéressent pas ? C'est pourtant fondamental pour supporter des tas de langues. Le bengali (bn) n'est pas une langue mineure, elle est énormément plus parlée et écrite que l'asturien (ast) ou même que le khmer (km) et l'ourdou (ur, variété de l'hindi en écriture arabe, quasiment la même langue à l'oral hormis l'accent), et c'est la seule langue officielle du Bengla Desh (et une langue officielle dans un Etat de l'Inde en plus de l'hindi, ou secondairement l'anglais comme lingua franca seulement au plan fédéral pour les Etats qui ne veulent pas être obligés d'utiliser l'hindi : la fédératin prend en charge elle-même les traductions nécessaires en hindi, les Etats n'ont pas besoin de les produire)... Le bengali est très bien supporté sur les principaux OS utilisables pour JOSM ou les éditeurs OSM en ligne. Que dire alors du luxembourgeois (lb), du limbourgeois (li), du vénitien (vec) ou du bavarois (bar), ou même (pratiquement qu'en France) l'occitan (oc), le breton (br), le corse (co) qui sont parfaitement supporté par JOSM ? Admet que ce sont deux points essentiels qu'il faudra bien régler rapidement... un jour... si on veut développer une carte réellement mondiale, par tous, et pour tous. Heureusement, les développeurs des OS et des navigateurs n'ont pas hésité à les régler. Je ne vois pas pourquoi les développeurs de JOSM ne devraient pas être convaincus aussi de leur utilité même si pour leur propre usage ils n'en ont pas encore besoin (mais ça va venir pour eux aussi). Le 3 février 2015 13:29, Marc SIBERT m...@sibert.fr a écrit : Le 3 février 2015 13:14, Philippe Verdy verd...@wanadoo.fr a écrit : OK, donc le problème d'affichage de cette page Wiki dans JOSM était inattendu, je ne l'ai pas vu car tout était clean dans le navigateur web qu'on utilise pour éditer le wiki. Oui tu as raison. TL;DR --- Il reste le problème que JOSM ne sait toujours pas afficher correctement plein de noms internationaux car sa gestion des polices est défective (et ce n'est même pas paramétrable dans les préférences de style pour indiquer de meilleures polices, apparemmentles polices sont codées en dur). Et que c'est un problème par exemple pour le bengali (inutilisable encore dans JOSM) où ce problème est majeur. Noter quand même que les navigateurs et les OS n'ont même plus besoin que les espaces fines (NNBSP) et autres espaces soient mappés dans les polices : à partir du moment où une police mentionne un glyphe pour l'espace standard, ils savent utiliser cet espace par défaut, et **tiennent compte** des propriétés des caractères Unicode pour savoir que ce sont des espaces, qu'ils ont une chasse ou pas du tout (ZWSP), qu'ils sont sécables ou non (NBSP et NNBSP), ou que leur chasse est fixe (espaces sinographiques par exemple): ils réutilisent ou ajustent les métriques du glyphe trouvé pour SPACE (qui est normalement toujours présent (dans toutes les polices) en fabriquant un glyphe synthétique. C'est géré dans leur moteur de rendu de texte (OpenType). Mais là le moteur d'AWT dans Java ne sait toujours pas le faire si ces caractères ne sont pas mappés dans la police utilisée : affiché un carré est clairement une erreur qui contrevient aux propriétés standard d'un caractère dont les propriétés Unicode sont celles d'un espacement. En attendant une éventuelle correction du moteur de rendu de texte défectif d'AWT dans Java, il sait tout de même gérer la sélection de polices : concernant la police à utiliser par défaut pour l'afchage d'une langue il serait souhaitable qu'au moins on puisse la choisir dans ses préférences, ne serait-ce que pour l'interface de JOSM lui-même ou les langues des libellés qu'on souhaite éditer afficher. Comme la police la plus complète n'est pas celle arbitrairement choisie par JOSM (qui se contente juste de savoir si on est sous Windows ou Mac OSX, mais en ignorant les versions exactes, il prend juste une police de +base connue pour être supportée par la plupart des versions, et ce n'est pas la meilleure : sous Windows 7 et supérieur Segoe UI est nettement mieux que Arial ou Verdana (et Segoe UI, qui a remplacé Arial et qui est aussi la police par défaut du système mappe bien les espaces fines). Les mêmes préférences de JOSM devraient aussi inclure une option pour ajuster la taille du texte de son interface : avec les écrans à très haute
Re: [OSM-talk-fr] Base de données pour le développement
L'API de test sert à tester... l'API. Si il manque des données sur une zone sur laquelle tu veux faire des tests et bien il suffit de les uploader au préalable (effectivement comme des nouveaux objets). Dans ton cas, vu que tu ne travaille que sur les bâtiments, tu peux récupèrer ceux-ci sur http://cadastre.gouv.fr/ tu les uploade sur l'API de test avant de tester tes scripts. Sinon tu peux créer une copie d'objets neufs à partir d'objets OSM actuels, JOSM permet de le faire très facilement: - download depuis l'API de données - tout sélectionner (ctrl-A) / copier (ctrl-C) - nouveau calque (ctrl-N) - coller (ctrl-V) - upload vers l'API de test... C'est comme ça que je procéderai. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM hors ligne
Le 03/02/2015 05:04, Eric SIBERT a écrit : Pour la question du serveur de tuiles, j'avais commencé à regarder et ça commençait à me paraître raisonnable: http://duemafoss.blogspot.fr/2014/02/installation-of-openstreetmap-server-on.html Le tuto que je recommande pour installer un serveur de tuile classique, c'est celui de http://switch2osm.org/ Les packages ubuntu sont maintenus, il n'y a rien à compiler, c'est clean. A installer sur une ubuntu 14.04 (LTS) pour être tranquille pour quelques années. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Oui. Mais dans ce cas particulier où il faut deux relations, addr:street dans la relation a du sens à partir du moment où le name de la relation *devrait* être suffixé. Oui, +99% des relations actuelles n'a pas besoin de tag addr:street supplémentaire vu que c'est le même (ce qui est alors cosmétique si on le répète). Mais dans les agglomérations de plusieurs communes on réglerait le problème correctement. Tout n'est pas à changer dans la base, seulement les rues limitrophes ou les rues d'une commune comportant des maisons d'une autre communes proche de cette rue. La solution que j'évoquais est propre. Elle résoud aussi le cas des ponts qui changent localement le nom d'une rue (dans quell segment de voie présent dans la relation le rapprochement BANO irait donc chercher le nom de rue à rapprocher?) Bref addr:street dans la relation n'est pas cosmétique. C'est plus le name de la relation qui l'est quand la relation mentionne un addr:street différent parce que le name doit être suffixé (avec le nom de commune, (entre parenthèses, ou avec une autre ponctuation). Je pense que pour en tenir compte dans le rapprochement la modif est mineure (après tout ce rapprochement a *déjà chargé* les données de la relation pour y trouver un tag name, il peut aussi regarder le tag addr:street pour voir s'il est présent et mentionne quelquechose de différent qui devrait être prioritaire ou utilisé seulement en seconde tentative tout en signalant l'erreur si le rapprochement n'a pas pu être fait sur le addr:street de la relation mais seulement sur son name).. Cela résoud aussi le cas des rues limitrophes des frontières internationales avec deux langues différentes (par exemple entre la France et la Flandre en Belgique) où tous les ways (ou bien seulement une partie) es partagée par deux relations (même si dans ce cas chaque relation a généralement son propre name=* distinct mais on peut effectivement là encore avoir des maisons situées en France dont le way le plus proche est entièrement en Flandre avec son nom en néerlandais et non son nom français (les ways concernés mentionnent les deux noms dans name=*, séparés en général par un /).. Le 3 février 2015 11:00, Vincent de Château-Thierry osm.v...@free.fr a écrit : De: Stéphane Péneau stephane.pen...@wanadoo.fr Je vois. Donc dans le cas d'une rue séparant 2 communes, avoir 2 relation associatedstreet avec sur le tag name Rue truc - Machin sur Seine, et Rue truc - Bidule sur yvette n'est pas une bonne idée ? Malgré l'aide que ça apporte pour les repérer dans la liste des relations ? Ou alors on efface la relation et on revient au schémas addr:housenumber + addr:street sur les noeuds adresse :-) Oops, mes excuses, en re-regardant le code je vois que ma mémoire a un peu rêvé. Dans le cas des relations associatedStreet, on ne va _pas_ chercher le nom des highways en 2e choix, ni en 1er, on prend le tag name de la relation, point. Ça mériterait d'être assoupli au vu de la discussion présente, en même temps jusque là ça n'a pas heurté grand monde, mais c'est peu étonnant vu le % de présence du tag name dans les relations associatedStreet (+99% en France). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Espaces demi m....
OK, donc le problème d'affichage de cette page Wiki dans JOSM était inattendu, je ne l'ai pas vu car tout était clean dans le navigateur web qu'on utilise pour éditer le wiki. Il reste le problème que JOSM ne sait toujours pas afficher correctement plein de noms internationaux car sa gestion des polices est défective (et ce n'est même pas paramétrable dans les préférences de style pour indiquer de meilleures polices, apparemmentles polices sont codées en dur). Et que c'est un problème par exemple pour le bengali (inutilisable encore dans JOSM) où ce problème est majeur. Noter quand même que les navigateurs et les OS n'ont même plus besoin que les espaces fines (NNBSP) et autres espaces soient mappés dans les polices : à partir du moment où une police mentionne un glyphe pour l'espace standard, ils savent utiliser cet espace par défaut, et **tiennent compte** des propriétés des caractères Unicode pour savoir que ce sont des espaces, qu'ils ont une chasse ou pas du tout (ZWSP), qu'ils sont sécables ou non (NBSP et NNBSP), ou que leur chasse est fixe (espaces sinographiques par exemple): ils réutilisent ou ajustent les métriques du glyphe trouvé pour SPACE (qui est normalement toujours présent (dans toutes les polices) en fabriquant un glyphe synthétique. C'est géré dans leur moteur de rendu de texte (OpenType). Mais là le moteur d'AWT dans Java ne sait toujours pas le faire si ces caractères ne sont pas mappés dans la police utilisée : affiché un carré est clairement une erreur qui contrevient aux propriétés standard d'un caractère dont les propriétés Unicode sont celles d'un espacement. En attendant une éventuelle correction du moteur de rendu de texte défectif d'AWT dans Java, il sait tout de même gérer la sélection de polices : concernant la police à utiliser par défaut pour l'afchage d'une langue il serait souhaitable qu'au moins on puisse la choisir dans ses préférences, ne serait-ce que pour l'interface de JOSM lui-même ou les langues des libellés qu'on souhaite éditer afficher. Comme la police la plus complète n'est pas celle arbitrairement choisie par JOSM (qui se contente juste de savoir si on est sous Windows ou Mac OSX, mais en ignorant les versions exactes, il prend juste une police de +base connue pour être supportée par la plupart des versions, et ce n'est pas la meilleure : sous Windows 7 et supérieur Segoe UI est nettement mieux que Arial ou Verdana (et Segoe UI, qui a remplacé Arial et qui est aussi la police par défaut du système mappe bien les espaces fines). Les mêmes préférences de JOSM devraient aussi inclure une option pour ajuster la taille du texte de son interface : avec les écrans à très haute résolution mais de petite taille on a des caractères difficiles à lire (c'est une question d'accessibilité, mais JOSM ne tient pas compte non plus des préférences d'affichage du texte dans l'OS, il ne tient compte que de la densité des pixels logiques par pouce logique pour savoir à combien de pixels logiques il faut taille une taille de 1 pouce logique, et ensuite déterminer le nombre de pixels logiques à utiliser pour un corps de police de 12 points logiques). Cette préférence du système est, par exemple, dans le panneau de configuration de Windows (options d'accessibilité) et même si JOSM ne sait pas la lire, au moins il pourrait avoir son propre réglage avec une réglette ou la saisie d'un taux (par exemple 120% pour agrandir le texte, et tous les widgets en conséquence, notamment les menus, les listes de tags, l'éditeur de tags, l'affichage des libellés sur la carte au lieu de les dimensionner absolument seulement en pixels logiques). Les navigateurs web supportent une telle préférence dans leurs paramètres de polices (en plus du niveau de zoom global de la page qui est ajustable à la volée, avec un accélérateur clavier comme Ctrl plus la touche + ou - du pavé numérique, ou par pincement-glissement à deux doigts sur un écran tactile, mais là je ne demande pas de supporter ce zoom pour l'interface, il est utilisé pour zoomer dans la carte mais n'a pas d'effet sur la taille de rendu des libellés et ne devrait pas en avoir). Note : les pixels logiques et pouces logiques ne sont pas destinés à être ajustables c'est une propriété nécessaire à l'affichage correcte des bitmaps, sans générer d''effets d'escaliers ou des pixels flous ou des artefacts de couleur, ils sont liés au matériel d'affichage utilisé : leur densité physique, leur taille associée à leur distance normale d'observation, la géométrie physique des pixels, leur colorimétrie... ce mapping des pixels physiques aux pixels logiques fait partie des données du pilote de la carte vidéo est n'est géré que par l'OS, ce n'est pas aux applications de le changer et s'ils ont accès aussi à cette information c'est pour des besoins très spécifiques d'ajustement précis de l'affichage des bitmaps, ou pour faire des captures écran, mais c'est dangereux d'y toucher concernant le rendu du texte et de l'interface visuelle comme les
Re: [OSM-talk-fr] Espaces demi m....
Le 3 février 2015 13:14, Philippe Verdy verd...@wanadoo.fr a écrit : OK, donc le problème d'affichage de cette page Wiki dans JOSM était inattendu, je ne l'ai pas vu car tout était clean dans le navigateur web qu'on utilise pour éditer le wiki. Oui tu as raison. TL;DR --- Il reste le problème que JOSM ne sait toujours pas afficher correctement plein de noms internationaux car sa gestion des polices est défective (et ce n'est même pas paramétrable dans les préférences de style pour indiquer de meilleures polices, apparemmentles polices sont codées en dur). Et que c'est un problème par exemple pour le bengali (inutilisable encore dans JOSM) où ce problème est majeur. Noter quand même que les navigateurs et les OS n'ont même plus besoin que les espaces fines (NNBSP) et autres espaces soient mappés dans les polices : à partir du moment où une police mentionne un glyphe pour l'espace standard, ils savent utiliser cet espace par défaut, et **tiennent compte** des propriétés des caractères Unicode pour savoir que ce sont des espaces, qu'ils ont une chasse ou pas du tout (ZWSP), qu'ils sont sécables ou non (NBSP et NNBSP), ou que leur chasse est fixe (espaces sinographiques par exemple): ils réutilisent ou ajustent les métriques du glyphe trouvé pour SPACE (qui est normalement toujours présent (dans toutes les polices) en fabriquant un glyphe synthétique. C'est géré dans leur moteur de rendu de texte (OpenType). Mais là le moteur d'AWT dans Java ne sait toujours pas le faire si ces caractères ne sont pas mappés dans la police utilisée : affiché un carré est clairement une erreur qui contrevient aux propriétés standard d'un caractère dont les propriétés Unicode sont celles d'un espacement. En attendant une éventuelle correction du moteur de rendu de texte défectif d'AWT dans Java, il sait tout de même gérer la sélection de polices : concernant la police à utiliser par défaut pour l'afchage d'une langue il serait souhaitable qu'au moins on puisse la choisir dans ses préférences, ne serait-ce que pour l'interface de JOSM lui-même ou les langues des libellés qu'on souhaite éditer afficher. Comme la police la plus complète n'est pas celle arbitrairement choisie par JOSM (qui se contente juste de savoir si on est sous Windows ou Mac OSX, mais en ignorant les versions exactes, il prend juste une police de +base connue pour être supportée par la plupart des versions, et ce n'est pas la meilleure : sous Windows 7 et supérieur Segoe UI est nettement mieux que Arial ou Verdana (et Segoe UI, qui a remplacé Arial et qui est aussi la police par défaut du système mappe bien les espaces fines). Les mêmes préférences de JOSM devraient aussi inclure une option pour ajuster la taille du texte de son interface : avec les écrans à très haute résolution mais de petite taille on a des caractères difficiles à lire (c'est une question d'accessibilité, mais JOSM ne tient pas compte non plus des préférences d'affichage du texte dans l'OS, il ne tient compte que de la densité des pixels logiques par pouce logique pour savoir à combien de pixels logiques il faut taille une taille de 1 pouce logique, et ensuite déterminer le nombre de pixels logiques à utiliser pour un corps de police de 12 points logiques). Cette préférence du système est, par exemple, dans le panneau de configuration de Windows (options d'accessibilité) et même si JOSM ne sait pas la lire, au moins il pourrait avoir son propre réglage avec une réglette ou la saisie d'un taux (par exemple 120% pour agrandir le texte, et tous les widgets en conséquence, notamment les menus, les listes de tags, l'éditeur de tags, l'affichage des libellés sur la carte au lieu de les dimensionner absolument seulement en pixels logiques). Les navigateurs web supportent une telle préférence dans leurs paramètres de polices (en plus du niveau de zoom global de la page qui est ajustable à la volée, avec un accélérateur clavier comme Ctrl plus la touche + ou - du pavé numérique, ou par pincement-glissement à deux doigts sur un écran tactile, mais là je ne demande pas de supporter ce zoom pour l'interface, il est utilisé pour zoomer dans la carte mais n'a pas d'effet sur la taille de rendu des libellés et ne devrait pas en avoir). Note : les pixels logiques et pouces logiques ne sont pas destinés à être ajustables c'est une propriété nécessaire à l'affichage correcte des bitmaps, sans générer d''effets d'escaliers ou des pixels flous ou des artefacts de couleur, ils sont liés au matériel d'affichage utilisé : leur densité physique, leur taille associée à leur distance normale d'observation, la géométrie physique des pixels, leur colorimétrie... ce mapping des pixels physiques aux pixels logiques fait partie des données du pilote de la carte vidéo est n'est géré que par l'OS, ce n'est pas aux applications de le changer et s'ils ont accès aussi à cette information c'est pour des
Re: [OSM-talk-fr] Base de données pour le développement
Bonjour à tous, Tout d'abord merci à tous pour vos différentes réponses. - Très intéressant de savoir qu'on a déjà des données libres pour les hauteurs des bâtiments de Paris ! J'imagine Christian que tu faisais allusion à ça : http://opendata.paris.fr/explore/dataset/volumesbatisparis2011/?tab=table ? Effectivement il est sans doute plus pertinent de s'occuper d'abord de ces imports avant de penser à celui de PSS. D'ailleurs j'avais remarqué que les coordonnées des arbres municipaux de Paris avait déjà été intégrées dans OSM, c'est une très belle valeur ajoutée.. - Pour PSS leur accord sera évidemment un pré-requis mais j'ai bon espoir. Malgré l'absence de retour sur le forum (c'est bien moi le user turman) j'ai contacté un administrateur. L'idée leur semble intéressante mais pour l'instant ça bloque un peu car il faudrait obtenir l'accord a posteriori de leurs 280 contributeurs pour autoriser l'utilisation des données dans OSM. Mais quand j'aurai leur retour je lancerai un nouveau thread pour les questions juridiques... - J'ai réussi à importer quelques données sur le serveur de test avec JOSM (soit en copiant directement les données depuis JOSM dans un nouveau calque, soit en modifiant un XML afin de supprimer les versions et en rendant négatif les ids+refs). Mais bon j'ai l'impression que dans mon cas c'est pas la bonne solution car les immeubles sont répartis sur toute la France et surtout parce qu'une fois que j'aurai uploadé les éléments sur le serveur de test ceux ci auront des IDs qui seront différents que ceux du serveur principal, comme l'a fait remarqué Philippe. Du coup ça m’empêchera de pouvoir tester mon programme puisque je me base sur les IDs récupérés via ma base PostGIS en local et ces IDS sont forcément ceux du serveur principal. - Du coup la meilleure solution dans mon cas serait peut-être d'avoir mon propre serveur de données en local ? Je pourrais ainsi importer toutes les données de la France en conservant les IDs originaux du serveur principal. Si j'ai bien compris il faudrait pour cela que j'utilise le schéma apidb (avec l'outil osmosis + certainement plein d'autres choses) et donc au final j'aurai les données OSM en double sur ma base PostGIS en local : - un schéma osm2pgsql me permettant de calculer l'osmId en fonction des coordonnées géographiques de l'immeuble. - un schéma apidb me permettant de simuler l'API en lecture et en écriture. Cela vous semble être la bonne approche ? Merci pour votre aide, Vincent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 26 futurs géomaticiens formés à OSM
@Nicolas. J'ai chargé mes présentations sur le Wiki OSM, elles sont accessibles depuis mon journal : https://www.openstreetmap.org/user/naomap/diary Antoine. Le 30/01/2015 18:17, Nicolas Moyroud a écrit : Bonjour Antoine, Bravo pour ces deux présentations OSM. Super boulot ! Merci également pour le partage. J'interviens sur quelques modules géomatique à l'université Montpellier 2 et j'ai eu l'occasion de leur faire quelques présentations OSM. C'est dommage, je n'ai pas pensé comme toi à compter les étudiants. ;-) Il y a des choses intéressantes dans tes slides dont je vais pouvoir m'inspirer pour améliorer mes supports. :-) As-tu pensé à mettre en téléchargement les fichiers sources qui ont servis à faire ces présentations ? Si oui où peut-on les récupérer ? Ce serait peut-être intéressant de les mettre en téléchargement sur une plate-forme qui ne nécessite pas de compte, par exemple sur openstreetmap.fr. Sinon je peux les héberger avec les supports de présentations que je met en ligne sur mon site. Merci a+ Le 30/01/2015 10:04, Antoine Riche a écrit : Bonjour, Lundi 26 janvier j'ai formé 26 étudiants de Licence Pro GGAT (Génie Géomatique pour l'Aménagement du Territoire) à Auch à l'utilisation des données OpenStreetMap. La matinée consistait en deux cours dont les supports sont disponibles en cc-by-sa : * Introduction à OpenStreetMap : http://www.slideshare.net/cartocite/introduction-openstreetmap * OpenStreetMap pour les géomaticiens : http://www.slideshare.net/cartocite/openstreetmap-pour-les-gomaticiens L'après-midi était consacrée à un TP, au cours duquel les étudiants ont intégré dans QGis données OSM de diverses manières : export Geofabrik avec styles 3Liz, Overpass Turbo, plugin QuickOSM, extraction de données brutes avec osmconvert et osmfilter. Antoine. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Espaces demi m....
J'approuve Philippe. JOSM a des progrès à faire là-dessus, les caractères affichés sur le calque OSM sont par exemple minuscules, et il n'y a à ma connaissance pas de possibilité pour changer facilement la taille de police des calques. Ces problèmes de taille de polices sont d'ailleurs je pense surtout visible sur les écrans à haute résolution type 1080p (mon cas). Le réglage des polices par défaut a cependant l'air d'être possible sur JOSM. Dans mon cas, l'utilisation du thème GTK+ permet d'utiliser la police (et la taille de police) définie par défaut sur le système. Il y quand même de nombreuses améliorations à apporter, je remarque par exemple que certains textes sont tronqués à cause de la taille de police (14) trop importante que j'utilise. Le mardi 3 février 2015, 13:55:51 Philippe Verdy a écrit : [...] ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 26 futurs géomaticiens formés à OSM
Le Tue, 03 Feb 2015 14:29:14 +0100, Antoine Riche antoine.ri...@ymail.com a écrit : Merci pour le partage. Je pense que je vais utiliser un maximum ton travail pour une présentation d'Openstreetmap à notre association Linux. merci a+ @Nicolas. J'ai chargé mes présentations sur le Wiki OSM, elles sont accessibles depuis mon journal : https://www.openstreetmap.org/user/naomap/diary Antoine. Le 30/01/2015 18:17, Nicolas Moyroud a écrit : Bonjour Antoine, Bravo pour ces deux présentations OSM. Super boulot ! Merci également pour le partage. J'interviens sur quelques modules géomatique à l'université Montpellier 2 et j'ai eu l'occasion de leur faire quelques présentations OSM. C'est dommage, je n'ai pas pensé comme toi à compter les étudiants. ;-) Il y a des choses intéressantes dans tes slides dont je vais pouvoir m'inspirer pour améliorer mes supports. :-) As-tu pensé à mettre en téléchargement les fichiers sources qui ont servis à faire ces présentations ? Si oui où peut-on les récupérer ? Ce serait peut-être intéressant de les mettre en téléchargement sur une plate-forme qui ne nécessite pas de compte, par exemple sur openstreetmap.fr. Sinon je peux les héberger avec les supports de présentations que je met en ligne sur mon site. Merci a+ Le 30/01/2015 10:04, Antoine Riche a écrit : Bonjour, Lundi 26 janvier j'ai formé 26 étudiants de Licence Pro GGAT (Génie Géomatique pour l'Aménagement du Territoire) à Auch à l'utilisation des données OpenStreetMap. La matinée consistait en deux cours dont les supports sont disponibles en cc-by-sa : * Introduction à OpenStreetMap : http://www.slideshare.net/cartocite/introduction-openstreetmap * OpenStreetMap pour les géomaticiens : http://www.slideshare.net/cartocite/openstreetmap-pour-les-gomaticiens L'après-midi était consacrée à un TP, au cours duquel les étudiants ont intégré dans QGis données OSM de diverses manières : export Geofabrik avec styles 3Liz, Overpass Turbo, plugin QuickOSM, extraction de données brutes avec osmconvert et osmfilter. Antoine. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Erreur sur le cadastre
Comme le dit le wiki OSM avec raison, le cadastre n'est pas fiable et à prendre à la lettre... - Données récentes manquantes - Données archaïques toujours présentes dans la base - Simples erreurs Le dimanche 4 janvier 2015, 11:27:53 David Crochet a écrit : Bonjour En corrigeant des erreurs via QA_script de JOSM, je constate des probable erreurs de cadastre : - Présence d'un bâtiment sur une parcelle, alors que le cadastre dit qu'il n'y a rien - Présence d'une parcelle avec une adresse à dix_lieux des autres de la même adresse - Double nom et double référence d'un même chemin communale. Certes, je peux bien comprendre que c'est pas à moi de gérer ce genre de souci, chacun se démerde avec ses emmerdes. Mais bon... Cordialement ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Espaces demi m....
En fait ce n'est pas tellement la taille des libellé dans l'affichage de la carte qui me gène (qu'ils soient petits évite aussi de cacher trop de chose : on devine mais en cas de doute on a encore l'onglet des propriétés pour les afficher clairement, sans superposition de traits et de couleurs). C'est surtout dans l'interface utilisateur (liste des tags, dialogues de saisie ou de configuration, menus, etc...) que c'est pénible (et que le support international des autres écritures est défectif). Certes affiche correctement le tibétain ou le birman est compliqué à inclure (dommage qu'il n'y ait pas un meilleur moteur de rendu de texte comme il en existe pour Eclipse) et leur normalisation assez récente (avec encore quelques problèmes de stabilité), mais pour le bengali c'est stable depuis longtemps et c'est une langue diablement importante. Et ma presbytie naissante (qu'on aura tous...) commence à être un vrai problème que la correction optique ne parvient pas à palier : les textes trop petits sont fatigants pour la vue et c'est difficile de voir des fautes mineures comme un accent oublié, même en français, alors que tout le reste de l'OS et le navigateur ont un réglage possible qui apporte un vrai confort visuel. Je m'énerve autant devant les étiquettes alimentaires (je veux lire scrupuleusement les compositions, notamment la nature des matières grasses et le taux de sel de plus en plus souvent excessif) devenues totalement illisibles où il me faut chercher une bonne source lumineuse pour accentuer les contrastes, en essayant de les lire sans mes lunettes (avec c'est impossible). Maintenant il m'arrive d'utiliser la caméra de mon smartphone pour zoomer dessus mais ce n'est pas évident de trouver le bon éclairage quand même le smartphone apporte de l'ombre et que son flash se réfléchit trop sur la surface et est inutilisable et la surface n'est pas non plus plane ou bien l'étiquette est sous un plastique alvéolé ou rainuré. Vivement la généralisation les étiquettes lisibles sur Internet par QR-code : OpenFoodFacts OK, mais les fabricants ou emballeurs devraient les rendre lisibles sur en données OpenData sur un site officiel non publicitaire contenant toutes les infos légales sur une fiche d'information normalisée, y compris les numéros de lots et dates de fraîcheur ou de conservation, qui peuvent être ajoutées (en plus du code produit EAN, et même le prix de vente sur le QRcode ou sur le code barre additionnel des points de vente). Certains points de vente (hypermarchés) vont aussi jusqu'à masquer ces infos en collant par dessus un emballage ou un autocollant de promo (impossible à décoller sans défaire le lot ou abimer l'emballage), mais souvent c'est de la faute même de leurs fournisseurs qui livrent ces promos (on achète d'abord, après on verra chez soi comment lire les infos sur les produits achetés, et on a des mauvaises surprises avec des produits qui dans une seule portion contiennent plus de 2 grammes de sel, plus que la quantité maximale pour toute une journée, le sel n'est là que pour masquer le fait que ce sont des produits totalement insipides, il remplace l'huile végétale et les épices... (Ça m'arrive de goûter et de jeter le tout tellement c'est gras et salé et souvent aussi sans texture : même un chien domestique n'en veut pas, et pourtant c'est un produit de marque connue, parfois avec force publicité, vendu plus cher qu'un premier prix d'hypermarché). Le 3 février 2015 20:18, Félix Marty felixma...@outlook.com a écrit : J'approuve Philippe. JOSM a des progrès à faire là-dessus, les caractères affichés sur le calque OSM sont par exemple minuscules, et il n'y a à ma connaissance pas de possibilité pour changer facilement la taille de police des calques. Ces problèmes de taille de polices sont d'ailleurs je pense surtout visible sur les écrans à haute résolution type 1080p (mon cas). Le réglage des polices par défaut a cependant l'air d'être possible sur JOSM. Dans mon cas, l'utilisation du thème GTK+ permet d'utiliser la police (et la taille de police) définie par défaut sur le système. Il y quand même de nombreuses améliorations à apporter, je remarque par exemple que certains textes sont tronqués à cause de la taille de police (14) trop importante que j'utilise. Le mardi 3 février 2015, 13:55:51 Philippe Verdy a écrit : [...] ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM hors ligne
Je continue à réfléchir au sujet, et je suis en train de me dire que le plus simple serait d'avoir quelque chose d'équivalent à ce que fait Kiwix pour wikipedia : un petit executable qui se contente d'afficher des données (tuiles précalculées) stockées localement sur un disque dur externe. Pour économiser l'espace disque nécessaire, j'envisage de n'afficher les tuiles à l'échelle mondiale que pour les premier niveaux de zooms. Reste à voir jusqu'à quel niveau je pourrais aller en fonction fde l'espace disque que ça consommerais. Pour les niveaux de zooms suivants, l'idée serait de récupérer les images uniquement pour les villes de plus de N habitants, N à déterminer en fonction de l'espace disque nécessaire. Premier problème : obtenir une liste de villes de plus de N habitants Je ne sais pas si le tag population est suffisamment fiable dans OSM ou si je dois utiliser des sources externes (http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Liste_de_villes). Deuxième problème : obtenir les bounding boxes de chaque vile de la liste. Je dois pouvoir récupérer les limites de villes avec overpass-api et faire un simple min/max sur les latitudes/longitudes des points que je récupère: http://overpass-turbo.eu/s/7s5 Question : est-ce que les relations admin_level=8 sont présentes dans OSM pour toutes les grandes villes ? Il y a déjà un problème pour le deuxième test que je fais après Paris : Krasnodar en Russie http://overpass-turbo.eu/s/7s7 Troisème problème : installeur un serveur de tuile et calculer les données pour les zones qui m'intéressent et aux niveaux de zoom qui m'intéressent. Sur ce point je pars de 0. Quatrième problème : l'affichage des données L'idéal serait un exécutable simple avec un menu open data qui permet de sélectionner le dossier contenant toutes les tuiles, et qui s'occupe d'afficher et de fournir les contrôles souris habituels (zoom avec la molette, pan avec un clic gauche + mouvement de la souris). Pour commencer, je dois pouvoir me débrouiller avec Firefox + OpenLayers : http://wiki.openstreetmap.org/wiki/OpenLayers_Local_Tiles_Example Commentaires et conseils bienvenus :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM hors ligne
Mon utilisation d'OSM en hors-ligne en consultation, c'est systématiquement via OsmAnd. Oui, c'est une application Android et ça ne répond pas exactement à la demande, mais c'est rudement pratique. La carte générale Monde pèse 180Mo et permet d'explorer relativement bien tout un tas d'endroits. Ensuite, faire un extrait personnalisé de quelques giga-octets (où l'on supprime tous les tags non utilisés pour le rendu, tous les bâtiments et toutes les géométries inférieures au 10 mètres et simplification des géométries restantes) par exemple permettrait d'avoir une belle carte jusqu’à un niveau de zoom non négligeable. En tous cas, il est certain que les données vectorielles pèsent moins que les tuiles pré-calculées. Il faut juste avoir de quoi les afficher correctement. (Encore et toujours ce compromis entre utilisation mémoire et puissance de calcul). 2015-02-03 10:26 GMT+01:00 Pierre Knobel pierr...@gmail.com: Je continue à réfléchir au sujet, et je suis en train de me dire que le plus simple serait d'avoir quelque chose d'équivalent à ce que fait Kiwix pour wikipedia : un petit executable qui se contente d'afficher des données (tuiles précalculées) stockées localement sur un disque dur externe. Pour économiser l'espace disque nécessaire, j'envisage de n'afficher les tuiles à l'échelle mondiale que pour les premier niveaux de zooms. Reste à voir jusqu'à quel niveau je pourrais aller en fonction fde l'espace disque que ça consommerais. Pour les niveaux de zooms suivants, l'idée serait de récupérer les images uniquement pour les villes de plus de N habitants, N à déterminer en fonction de l'espace disque nécessaire. Premier problème : obtenir une liste de villes de plus de N habitants Je ne sais pas si le tag population est suffisamment fiable dans OSM ou si je dois utiliser des sources externes (http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Liste_de_villes). Deuxième problème : obtenir les bounding boxes de chaque vile de la liste. Je dois pouvoir récupérer les limites de villes avec overpass-api et faire un simple min/max sur les latitudes/longitudes des points que je récupère: http://overpass-turbo.eu/s/7s5 Question : est-ce que les relations admin_level=8 sont présentes dans OSM pour toutes les grandes villes ? Il y a déjà un problème pour le deuxième test que je fais après Paris : Krasnodar en Russie http://overpass-turbo.eu/s/7s7 Troisème problème : installeur un serveur de tuile et calculer les données pour les zones qui m'intéressent et aux niveaux de zoom qui m'intéressent. Sur ce point je pars de 0. Quatrième problème : l'affichage des données L'idéal serait un exécutable simple avec un menu open data qui permet de sélectionner le dossier contenant toutes les tuiles, et qui s'occupe d'afficher et de fournir les contrôles souris habituels (zoom avec la molette, pan avec un clic gauche + mouvement de la souris). Pour commencer, je dois pouvoir me débrouiller avec Firefox + OpenLayers : http://wiki.openstreetmap.org/wiki/OpenLayers_Local_Tiles_Example Commentaires et conseils bienvenus :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 03/02/2015 10:13, Christian Quest a écrit : Pas si cosmétique pour la gestion des adresses. C'est là qu'on retrouve facilement (un niveau d'indirection via la relation) le nom de la voie correspondant aux adresses, si il manque il faut passer en revue les membres street pour trouver le nom, donc un deuxième niveau d'indirection. Il n'est pas utilisé pour le rendu carto, mais c'est pas pour cela qu'on peut considérer qu'il soit cosmétique. Je vois. Donc dans le cas d'une rue séparant 2 communes, avoir 2 relation associatedstreet avec sur le tag name Rue truc - Machin sur Seine, et Rue truc - Bidule sur yvette n'est pas une bonne idée ? Malgré l'aide que ça apporte pour les repérer dans la liste des relations ? Ou alors on efface la relation et on revient au schémas addr:housenumber + addr:street sur les noeuds adresse :-) Stf ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Espaces demi m....
Je n'ai rien contre la correction de mes fautes d'orthographe, car j'en fait, comme des contre-sens et plein d'autres choses aussi. Mais quand personne ne traduit les libellés, je le fais, mais rien ne t’empêche de le faire mieux que moi. Là seulement, il y a un problème car les caractères que tu as utilisé sont mal rendus dans JOSM/Windows. Peut-être que c'est bien ailleurs (j'en doute), peut-être que c'est la faute de JOSM... et de ceux qui le programment, mais ça n'est pas mon sujet. Je te demande juste de retirer ces caractères qui produisent des choses inesthétiques. Pour tout le reste, juste fait le, et fait le bien (mieux que moi), je n'en prendrais pas ombrage, au contraire, je ferais autre chose. A+ Marc Sibert m...@sibert.fr Le 1 février 2015 20:38, Philippe Verdy verd...@wanadoo.fr a écrit : Et non ce n'est PAS un fichier de config de JOSM, JOSM se contente de lire le HTML généré par une page wiki de JOSM. Si les fautes d'orthographe te plaisaient, mois pas. A ce sujet je ne sais pas qui a fait la traduction française de plein de trucs dans JOSM mais elle est bourrée de fautes (et aussi de contre-sens et faux-amis) ! Ca commence à m'agacer de les voir en permanence dans l'interface depuis un moement sans personne pour les corriger. Le 1 février 2015 20:32, Philippe Verdy verd...@wanadoo.fr a écrit : Quel espaces ??? Ce sont les indentations des puces de la page wiki et elles y sont comem sur les autres pages. Mes contribs sur cette page consistaient à corriger les fôtes de français. Le 1 février 2015 19:51, Marc Sibert m...@sibert.fr a écrit : Bonjour, Il y a un personnage maladroit qui a ajouté des espaces de m... dans les fichiers de config de JOSM. Des trucs qui sont placés avant les signes de ponctuation double, un certain verdy_p. S'il peut faire marche arrière immédiatement, ça éviterait des (pas) jolis carrés dans mon JOSM. Merci... pour la correction (pas pour la contribution). A+ -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 03/02/2015 11:00, Vincent de Château-Thierry a écrit : Oops, mes excuses, en re-regardant le code je vois que ma mémoire a un peu rêvé. Dans le cas des relations associatedStreet, on ne va _pas_ chercher le nom des highways en 2e choix, ni en 1er, on prend le tag name de la relation, point. Ça mériterait d'être assoupli au vu de la discussion présente, en même temps jusque là ça n'a pas heurté grand monde, mais c'est peu étonnant vu le % de présence du tag name dans les relations associatedStreet (+99% en France). vincent En fait, si j'ai lancé cette question, c'est en partie suite à ce que j'ai lu dans la discussion sur la liste tagging à propos des relations associatedStreet. Quelqu'un disait que le tag name de la relation était conseillé, mais pas obligatoire, et que ce name n'avait pas à être utilisé pour l'adressage : http://gis.19327.n5.nabble.com/Deprecation-of-associatedStreet-relations-tp5830903p5831243.html Stf (j'en vois un en train de sourire devant son écran :-) ) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM hors ligne
On 2/3/15, sly (sylvain letuffe) lis...@letuffe.org wrote: ça manque encore de précisions il me semble, tu as besoin de quoi par services cartographiques ? Initialement je pensais à plusieurs services : tuiles, routage type OSRM et minage de la base de données (requêtes overpass). Mais là pour l'instant je pense qu'avoir les tuiles serait déjà pas mal, même à un niveau de zoom limité. Un rendu à la volée à partir des données d'OSMAnd serait effectivement une bonne solution. En additionnant toutes les tailles sur la page http://download.osmand.net/list.php on arrive à seulement 31Go. Reste à trouver un moteur de rendu qui digère les fichier OBF et fonctionne sous Windows ou Linux. Ou un émulateur Android. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rencontre mensuelle OSM-Lyon 10/02/2015 18h30 - Invitation + OdJ
Bonsoir à tous Les mappeurs OSM de Lyon se rencontrent régulièrement le 2ème mardi de chaque mois, et chacun peut s'inviter et participer à ces rencontres. La prochaine aura lieu : le MARDI 10 FEVRIER à partir de 18h30 au bistrot CHEZ THIBAULT, 80 rue Montesquieu, 69007 LYON Accès : M° Saxe-Gambetta; C4, C12, C14 Thibaudière ; Vélo'V Jaurès/Thibaudière. Le CR de la rencontre précédente se trouve sur la page du Wiki-OSM au lien : http://wiki.openstreetmap.org/wiki/Lyon/Reunion_13_janvier_2015 Si vous souhaitez mettre un sujet particulier à l'ordre du jour, vous pouvez commenter la page préparatoire de la rencontre à venir au lien : http://wiki.openstreetmap.org/wiki/Lyon/Reunion_10_fevrier_2015 Venez nombreux ! Amicalement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 03/02/2015 06:37, Vincent de Château-Thierry a écrit : Bonjour, Le 03/02/2015 02:25, Philippe Verdy a écrit : Le rapprochement BANO n'utilise-t-il pas de préférence le tag addr:street:* (plutot que name=*) quand il est présent ? Du tout, non. Sur les entités associatedStreet, on a très souvent un tag name, et, d'après taginfo.fr, jamais de tag addr:street : http://taginfo.openstreetmap.fr/tags/type=associatedStreet#combinations Il y a 2 cas pour un objet portant le tag addr:housenumber, - rechercher un tag addr: street sur le même objet, - ou bien l'inclusion de l'objet à une relation associatedStreet. Deux sous-possibilités pour les objets des relations : soit la relation a un tag name, et on le prend, soit elle n'en a pas et on va chercher le tag name des membres de la relation ayant le rôle 'street'. Pour le moment, j'ai juste créé les deux relations (pour lesquelles JOSM a râlé, puisqu'elles concernaient le même objet) sans name (il est sur le highway) avec chacune son ref:FR:FANTOIR. C'est donc suffisant pour que BANO retrouve ses petits ? http://www.openstreetmap.org/way/22755613 http://www.openstreetmap.org/relation/4548496 http://www.openstreetmap.org/relation/4548495 Oups !!! Je viens de voir que le rôle des relations n'est pas bon, il faut que je le corrige ... Lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM hors ligne
Le dimanche 1 février 2015 18:04:19, Pierre Knobel a écrit : Mais là il ne s'agit pas de contribuer, juste d'avoir accès à des services cartographiques pour économiser les accès web à GoogleMaps et OSM, ça manque encore de précisions il me semble, tu as besoin de quoi par services cartographiques ? histoire de pouvoir continuer à explorer le monde et planifier les prochaines vacances même quand internet nous lâche au boulot. (...) mais on n'a pas encore de bonne solution pour la problématique Je suis dans la brousse avec mon ordinateur portable, j'aimerais bien savoir à quoi ressemble Tokyo ou Reykjavik. Planifier ses vacances, explorer le monde, voir à quoi ressemble la rue machin à Tokyo, trouver les points de vues d'une coline de la réunion, ce genre de besoin peuvent être répondue par une appli qui stocke les données en vectoriel et te fait le rendu à la vollée. osmand sur android me vient en tête, beaucoup s'en servent pour du routage, mais vu tout ce qu'il affiche, moi je m'en sers pour chercher des idées de rando quand je suis dans le TGV et ça le fait bien Il doit y en avoir d'autres, plus ordi frendly -- sly (sylvain letuffe) http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Pas si cosmétique pour la gestion des adresses. C'est là qu'on retrouve facilement (un niveau d'indirection via la relation) le nom de la voie correspondant aux adresses, si il manque il faut passer en revue les membres street pour trouver le nom, donc un deuxième niveau d'indirection. Il n'est pas utilisé pour le rendu carto, mais c'est pas pour cela qu'on peut considérer qu'il soit cosmétique. Le 03/02/2015 07:12, Stéphane Péneau a écrit : Bonjour, Le 03/02/2015 06:37, Vincent de Château-Thierry a écrit : - ou bien l'inclusion de l'objet à une relation associatedStreet. Deux sous-possibilités pour les objets des relations : soit la relation a un tag name, et on le prend, soit elle n'en a pas et on va chercher le tag name des membres de la relation ayant le rôle 'street'. Je croyais que le tag name d'une relation AssociatedStreet était plus cosmétique qu'autre chose. Si oui, ne faudrait-il pas utiliser en priorité le tag name des membres street de la relation ? Stéphane ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base de données pour le développement
Le 02/02/2015 23:37, Vincent de Château-Thierry a écrit : Bonsoir et bienvenue, Le 02/02/2015 23:12, Vincent Frison a écrit : La base de données concerne environ 40 000 immeubles répartie sur toute la France mais de toute façon je comptais bien lancer un nouveau sujet pour détailler et demander des conseils techniques voir légaux. Pour l'instant mon problème est juste sur la base de données de test... Ou bien demander des conseils légaux voire techniques ;) Tu as des infos sur la licence associée aux données de la base PSS ? C'est, comme pour tout apport de données d'une base externe, la première question à voir, sachant qu'elle peut à elle toute seule bloquer la suite. Je vois que ce fil : http://www.pss-archi.eu/forum/viewtopic.php?id=33791 n'a pas déchaîné les foules, et comme turman (toi ?) je n'ai rien trouvé sur le statut de cette base. vincent Bien sûr vérifier toujours le juridique avant de perdre du temps en technique non utilisable si on n'a pas de feu vert juridique... Pour info, sur Paris on a des infos en opendata sur les hauteurs de bâtiments. Les intégrer serait déjà un super projet... et là c'est feu vert sur la licence (ODbL). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
Le 03/02/2015 10:47, Stéphane Péneau a écrit : Le 03/02/2015 10:13, Christian Quest a écrit : Pas si cosmétique pour la gestion des adresses. C'est là qu'on retrouve facilement (un niveau d'indirection via la relation) le nom de la voie correspondant aux adresses, si il manque il faut passer en revue les membres street pour trouver le nom, donc un deuxième niveau d'indirection. Il n'est pas utilisé pour le rendu carto, mais c'est pas pour cela qu'on peut considérer qu'il soit cosmétique. Je vois. Donc dans le cas d'une rue séparant 2 communes, avoir 2 relation associatedstreet avec sur le tag name Rue truc - Machin sur Seine, et Rue truc - Bidule sur yvette n'est pas une bonne idée ? Malgré l'aide que ça apporte pour les repérer dans la liste des relations ? Ou alors on efface la relation et on revient au schémas addr:housenumber + addr:street sur les noeuds adresse :-) Les relations marchent bien aux limites administrative comme celui là, mais également dans une section avec un nom plus particulier que celui de la rue, tout en étant dans la rue, un pont par exemple. Pour moi c'est le nom de la relation qu'il faut prendre de préférence à ceux des segments pour les adresses. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO : non rapprochement highway avec code FANTOIR
De: Stéphane Péneau stephane.pen...@wanadoo.fr Je vois. Donc dans le cas d'une rue séparant 2 communes, avoir 2 relation associatedstreet avec sur le tag name Rue truc - Machin sur Seine, et Rue truc - Bidule sur yvette n'est pas une bonne idée ? Malgré l'aide que ça apporte pour les repérer dans la liste des relations ? Ou alors on efface la relation et on revient au schémas addr:housenumber + addr:street sur les noeuds adresse :-) Oops, mes excuses, en re-regardant le code je vois que ma mémoire a un peu rêvé. Dans le cas des relations associatedStreet, on ne va _pas_ chercher le nom des highways en 2e choix, ni en 1er, on prend le tag name de la relation, point. Ça mériterait d'être assoupli au vu de la discussion présente, en même temps jusque là ça n'a pas heurté grand monde, mais c'est peu étonnant vu le % de présence du tag name dans les relations associatedStreet (+99% en France). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM hors ligne
Pour la question du serveur de tuiles, j'avais commencé à regarder et ça commençait à me paraître raisonnable: http://duemafoss.blogspot.fr/2014/02/installation-of-openstreetmap-server-on.html https://www.evernote.com/pub/view/shahada130/ickywikipublicnotebook/7699d902-ca55-4709-afd4-1c614b57671e?locale=fr#st=pn=7699d902-ca55-4709-afd4-1c614b57671e J'y pense (et puis j'oublie faute de temps...) pour me faire mon rendu personnalisé sur une zone limitée avec un serveur SME-server (http://www.contribs.org , qui utilise CentOs comme distro sous-jacente) éventuellement virtualisé sur une station de travail. Après faut voir la gestion du cache sachant que les données ne sont pas mises à jour: durée de vie infinie et écrasement uniquement en cas de saturation? Il y a quelques temps, une personne avait aussi présenté un rendu pré-calculé sur le Sahara. Calcul des tuiles sur une station de travail et transfert sur un raspberry. Ça n'allait pas très loin en zoom. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
