Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
Le 22 janvier 2014 23:59, Vincent de Château-Thierry v...@laposte.net a écrit : En fait je n'ai pas de souci dès qu'on sait rattacher le n° à quelque chose. Mon exemple avec l'école est donc mal choisi, vu que vous lui tordez le cou :-). Pour le dire autrement : ce que je regrette comme pratique, c'est celle de poser un n° comme un node isolé de tout (building comme amenity ou landuse), surtout lorsque l'environnement est truffé de points d'accroche potentiels, dont les ways building bien sûr, mais pas que, comme vous le soulignez. Mais l'essentiel c'est bien de connaître le point d'accès d'une adresse, non? A la limite, l'adresse sur le contour d'un building c'est important quand ce même building représente un amenity... mais dans le cas d'une simple habitation privée? Romain ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
Bonjour, Le 23/01/2014 09:11, Romain MEHUT a écrit : Mais l'essentiel c'est bien de connaître le point d'accès d'une adresse, non? Ça c'est dans une optique centrée sur le routage (soit un usage bien réel, c'est clair). Mais on peut aussi se dire que l'adresse a un rayonnement plus large que le simple point d'accès. Une adresse concerne parfois une simple cage d'escalier d'immeuble, mais va jusqu'à plusieurs parcelles cadastrales, d'où la remarque de Christian. Un point d'accès aura ses tags en propre, notamment entrance=* [1]. Les infos d'adresse peuvent être portées par le même point, mais dans ce cas on peut espérer que le node qui porte tous ces tags participe à la délimitation du terrain. C'est l'exemple de l'école. Pour prendre un autre exemple : une bibliothèque municipale, qui occupe un bâtiment en retrait de la rue, avec de la verdure devant, sans muret ou grille. En plaçant le point d'adresse sur le trottoir, à l'endroit où démarre par exemple un footway qui va jusqu'à l'entrée du bâtiment, on n'a pas de lien entre l'adresse et le bâtiment. Déduire l'adresse de la bibliothèque, pas forcément pour y accéder en guidage, mais pour combiner les infos adresse et nature ou nom du bâtiment, n'a rien de trivial, puisque le lien entre les deux n'est pas organisé dans la base. D'où ma préférence pour associer explicitement les infos d'adresse au bâtiment (public comme privé, au passage). Cette association est une valeur ajoutée. vincent [1] : http://wiki.openstreetmap.org/wiki/Key:entrance ps. si le service que permet l'outil de Tyndare se met en place de manière pérenne, nulle doute que la discussion reviendra rapidement sur talk-fr. On gagnerait en efficacité en synthétisant la présente discussion quelque part sur le wiki, avec les arguments pour et contre chaque méthode. ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
ps. si le service que permet l'outil de Tyndare se met en place de manière pérenne, nulle doute que la discussion reviendra rapidement sur talk-fr. On gagnerait en efficacité en synthétisant la présente discussion quelque part sur le wiki, avec les arguments pour et contre chaque méthode. Un avantage du point adresse non lié a un batiment, c'est que si le batiment change il n'y a rien a faire pour l'adresse. Et c'est plus fréquent que je l'imaginait, a Rennes j'ai essayé de garder le bati a jour en faisant des différentiels de cadastre, j'ai arrêté au bout de quelques mois car c’était épuisant avec toutes les maisons écroulé/reconstruite ou qui font des extensions. -- JB ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
Le 23 janvier 2014 13:14, Vincent de Château-Thierry v...@laposte.net a écrit : Ça c'est dans une optique centrée sur le routage (soit un usage bien réel, c'est clair). Mais on peut aussi se dire que l'adresse a un rayonnement plus large que le simple point d'accès. Une adresse concerne parfois une simple cage d'escalier d'immeuble, mais va jusqu'à plusieurs parcelles cadastrales, d'où la remarque de Christian. Un point d'accès aura ses tags en propre, notamment entrance=* [1]. Les infos d'adresse peuvent être portées par le même point, mais dans ce cas on peut espérer que le node qui porte tous ces tags participe à la délimitation du terrain. C'est l'exemple de l'école. Pour prendre un autre exemple : une bibliothèque municipale, qui occupe un bâtiment en retrait de la rue, avec de la verdure devant, sans muret ou grille. En plaçant le point d'adresse sur le trottoir, à l'endroit où démarre par exemple un footway qui va jusqu'à l'entrée du bâtiment, on n'a pas de lien entre l'adresse et le bâtiment. Déduire l'adresse de la bibliothèque, pas forcément pour y accéder en guidage, mais pour combiner les infos adresse et nature ou nom du bâtiment, n'a rien de trivial, puisque le lien entre les deux n'est pas organisé dans la base. D'où ma préférence pour associer explicitement les infos d'adresse au bâtiment (public comme privé, au passage). Cette association est une valeur ajoutée. Sauf que s'agissant d'un bâtiment public, on peut mettre effectivement l'adresse jusqu'au point d'accès puisqu'il n'y a pas à traverser un espace privatif. Romain ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
Le 23/01/2014 13:35, Christian Quest a écrit : Je comprends tout à fait le besoin de lier tel ou tel objet (comme un bâtiment) à une adresse, mais de là à considérer que c'est le bâtiment qui doit porter l'adresse me semble abusif. Ça n'est pas la seule solution. Mais encore une fois, celle (la seule) qui me rebute est celle où l'adresse est portée par un point isolé, lié à rien. En fait une adresse c'est comme un point kilométrique sur une voirie d'accès. C'est bien pour ça que les numéros sont liés à la voirie (cas général). Une parcelle de terrain est proche d'un (ou plusieurs) de ces points, mais là aussi il n'y a pas toujours de lien 1 vers 1 adresse/parcelle comme pour les bâtiments. Je pense que c'est pour cette raison qu'on a du mal à se mettre d'accord sur un modèle. Je pense qu'on commence à bien distinguer les approches. D'un côté, ceux pour qui adresse = point d'accès. De l'autre, ceux pour qui adresse = emprise incluant (notamment) des bâtiments. Je suis pour la 2e approche. Dans le cas d'une habitation sur une parcelle, avec une seule adresse associée, on ne peut pas mettre d'adresse sur l'emprise, vu qu'on ne trace pas les limites de parcelle dans OSM. Le bâtiment est alors la solution de repli, puisqu'il matérialise, indirectement, l'existence d'une propriété avec une adresse. On aurait les parcelles, c'est bien sûr la parcelle qui porterait l'adresse, bien mieux que le bâtiment. On saurait par suite - emmener à l'adresse, en combinant les infos d'adresse et la situation du point entrance - donner la surface bâtie de l'adresse - donner le périmètre de la propriété de l'adresse - etc tout simplement parce qu'on aurait un lien entre les infos d'adresse et ce qui se situe à cette adresse. J'espère vous montrer avec cet exemple que l'intérêt d'un lien entre adresse et emprise physique dépasse le simple besoin de se rendre à une adresse, dans une optique de routage. Le minimum sur lequel on semble plutôt d'accord c'est bien cette notion de position ponctuelle lié à un filaire de voirie... non ? Là je ne comprends pas ce que tu veux dire, car ça m'évoque la solution 3), contre laquelle je suis (= le numéros qui flottent dans le vide). Mon impression, si on revient au tiercé d'hier, est que le consensus serait plutôt sur la solution 1) : les adresses comme des ponctuels (des nodes) qui font partie d'un way, de type amenity, building, landuse, etc. vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
De : Christian Quest Je rappelle mon tiercé... 1 3 2 Le tien: 1 2 3 Lisez Bilto :-) Le cas 1 est facile à gérer pour les bâtiments en bord de voirie. Au pire si le numéro est flottant, on peut le reprojeter sur le bâtiment le plus proche dans un rayon de seulement quelque m. Pour notre intégration, il faudrait que cette reprojection soit faite de la façon la plus automatique possible, sinon ça prend un temps fou à faire et on fait ça comme un robot... donc à automatiser. Le problème du temps à passer est bien réel, vue l'ampleur de la tâche. Tyndare a montré qu'on savait retrouver une info de parcelle. Je ne sais pas si ça va jusqu'à savoir récupérer la géométrie de la parcelle, mais on doit pouvoir avancer dans cette direction. Une fois la limite de la parcelle reconstituée, il est trivial de retrouver quel(s) bâtiment(s) en font partie. Et, dans le cas d'une parcelle à une seule adresse, on devrait pouvoir affecter le n° d'adresse au bâtiment ayant, par exemple, la plus grande surface parmi ceux inclus. C'est de la reflexion à voix haute sans test, mais ça me semble une logique de départ à creuser. Ça ne réglerait que le cas de 1 adresse pour n parcelles (n = 1) mais c'est déjà énorme. Pour le cas de n adresses pour une parcelle, on devrait intégrer manuellement, un peu comme ce que les fichiers d'associatedStreet proposent en ce moment. En tout cas ça mérite d'être creusé. Là où ça se complique c'est quand le bâtiment n'est pas en bord de voirie... là moi je préfère le point adresse en bord de voirie (cas 3, en gros ce qu'on peut constater sur le terrain, c'est à dire l'endroit où il y a la plaque ou l'entrée ou la boite aux lettres) et toi tu le fait migrer sur le bâtiment principal sur la parcelle (2) vu qu'on n'a pas la parcelle. Si je préfère le 3, c'est qu'on reste sur un modèle plus proche du cas 1, c'est à dire qu'on a du ponctuel, plus ou moins aligné sur la voirie. J'ai l'impression que c'est plus cohérent. Oui, c'est plus aligné, visuellement, une fois sur une carte. Après, quitte à converger avec le 1), rabattre l'adresse sur le bâtiment sous forme de ponctuel, symboliquement là où on imagine qu'est la porte d'entrée, ça ne me dérange pas plus que ça. Mais au moins on lie l'adresse à quelque chose :-) Et en reprenant l'idée dite plus haut, on pourrait aussi tenter d'automatiser ce rapprochement, toujours avec la garantie de jouer dans une unique adresse grâce aux limites de parcelle. nb. il va sans dire que quand j'évoque d'utiliser la géométrie des parcelles, c'est uniquement pour un traitement back-office. D'aucune manière il ne s'agirait de rendre ce contenu disponible en format OSM. vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
De toute façon, vu le volume de données considéré, un maximum doit être fait automatiquement si on veut utiliser au mieux le temps de cerveau disponible de la fourmis OSMienne et lui éviter des TMS ;) -- Christian Quest - OpenStreetMap France ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
Je récupère bien la géométrie des parcelles, je peut générer facilement un fichier .osm correspondant si certains sont intéressés à pouvoir réaliser ce genre de traitement, mais mon tiercé étant le même que Christian, je ne suis pas super motivé pour le faire moi même. Le 23 janvier 2014 14:54, V de Chateau-Thierry v...@laposte.net a écrit Tyndare a montré qu'on savait retrouver une info de parcelle. Je ne sais pas si ça va jusqu'à savoir récupérer la géométrie de la parcelle, mais on doit pouvoir avancer dans cette direction. Une fois la limite de la parcelle reconstituée, il est trivial de retrouver quel(s) bâtiment(s) en font partie. Et, dans le cas d'une parcelle à une seule adresse, on devrait pouvoir affecter le n° d'adresse au bâtiment ayant, par exemple, la plus grande surface parmi ceux inclus. C'est de la reflexion à voix haute sans test, mais ça me semble une logique de départ à creuser. Ça ne réglerait que le cas de 1 adresse pour n parcelles (n = 1) mais c'est déjà énorme. Pour le cas de n adresses pour une parcelle, on devrait intégrer manuellement, un peu comme ce que les fichiers d'associatedStreet proposent en ce moment. En tout cas ça mérite d'être creusé. ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
De : Tyndare Je récupère bien la géométrie des parcelles, je peut générer facilement un fichier .osm correspondant si certains sont intéressés à pouvoir réaliser ce genre de traitement, mais mon tiercé étant le même que Christian, je ne suis pas super motivé pour le faire moi même. Volontaire :-) Si tu peux, quand tu auras branché une sortie .osm, me donner une URL où je peux générer ces fichiers, je teste volontiers. merci vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] Intégrer la date aux requêtes OAPI
Bonsoir, Est-il possible d'intégrer la date d'édition des objets dans une requête OAPI ? Je me pose cette question, car utilisant aujourd'hui l'OAPI pour récupérer quelques objets (~200 pour l'instant), je vais bientôt importer des choses comme les pylônes et poteaux électriques tous les jours. Donc le jeu de retour sera de taille beaucoup plus importante, cependant un petit n'ombre de ces objets change quotidiennement. Vu qu'il n'y a pas de diff (et que je n'ai pas envie de processer les diffs standards), je me disais qu'utiliser la date d'édition pourrait réduire la quantité de données obtenue. Est-ce le bon raisonnement ? D'autres outils existent-ils ? Merci pour vos retours. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] LeafletJS et MapCSS
Bonsoir, Je crois que la réponse de Leaflet sur cette question est on ne peut plus claire : https://twitter.com/InfosReseaux/status/425029136910790656 Néanmoins utiliser Khotic n'est pas possible : mon service ne donne pas de tuilage vectoriel. Quelqu'un aurait-il une autre idée ? *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 16 janvier 2014 15:28, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Le service qui fourni les données à mes applis délivre déjà des documents xml au format OSM. Il suffit de fournir le métier GeoJSON et de spécifier l'en-tête Accept lors de la requête. Passer par JOSM n'est clairement pas souhaitable dans ce cas puisqu'on a des échanges BDD - service - appli client LeafletJS. Exemple : http://www.infos-reseaux.com/apps/ADSLObs/carte-nra-nro/ (aller sur Paris intramuros, il y a quelques markers visibles) L'appli est en continuous download selon la bbox visible par l'utilisateur. Cependant, ce qui sera le plus problématique n'est pas le format mais le découpage en tuiles dans l'URL. Je crois que Kothic fait des demandes de tuiles vectorielles, avec le niveau de zoom et X/Y dans l'URL à l'image des tuiles bitmap. Mon service n'est pas prévu pour cela, il est uniquement conforme aux appels /map de l'API 0.6 d'OSM. Peut-être existe-t-il quelque chose de moins lourd / intégré dans l'écosystème OSM ? La prochaine étape c'est de faire un ITOworld avec différent rendus, je compte me passer de cette usine à gaz pour l'instant. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 16 janvier 2014 13:52, Ab_fab gamma@gmail.com a écrit : Bon à savoir : Selon http://josm.openstreetmap.de/ticket/7307 Il est possible de sauvegarder un calque JOSM au format GeoJSON. Les relations ne semblent pas supportées. Je constate que c'est un habitué de la liste qui a travaillé sur le ticket. ;-) A toi de voir si c'est transposable pour ton projet. Le 16 janvier 2014 12:36, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Bonjour Ab, Merci pour cet exemple :) En effet ORM tourne avec Kothic. https://github.com/kothic Il permet de rendre du GeoJSON suivant des règles MapCSS et de s'interfacer avec LeafletJS. C'est une solution entre tout passer par des overlays LeafletJS et un mapnik dédié avec des dalles bitmap. Néanmoins il faudrait que je sois en mesure de fournir à Kothic du GeoJSON et ma BDD n'a rien à voir avec celle d'OSM. L'intégration d'OSM2pgsql + josn_getter.py semble pour l'instant compromise. Dommage parce que c'était interessant mis à part ça :) *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 16 janvier 2014 11:41, Ab_fab gamma@gmail.com a écrit : Bonjour François, Le site OpenRailwayMap [1] fonctionne beaucoup à base d'overlays et la carte en ligne fonctionne manifestement avec Leaflet. Les overlays sont construits à l'aide de tuiles vectorielles (et non pas images). Sur le Github du projet [2] on peut voir que les styles associés [3] sont au format .mapcss C'est peut être une piste intéressante à creuser pour toi Bonne journée - [1] http://www.openrailwaymap.org/ [2] https://github.com/rurseekatze/OpenRailwayMap [3] https://github.com/rurseekatze/OpenRailwayMap/tree/master/styles Le 16 janvier 2014 11:31, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Bonjour, J'utilise depuis quelques temps LeafletJS pour intégrer OSM sur mes pages web et certaines de mes applications ont massivement recours aux markers et autres dessins. Ces overlays/layers reçoivent des informations de style au cas par cas, selon un formalisme propre à LeafletJS. Ces informations sont déterminées sur la base des données qu'ils représentent, sans forcément de grande surprise là dessus. Pourtant je crois que pour avoir une meilleure maitrise du rendu graphique, le recours à des documents MapCSS rendrait la démarche plus automatique, efficace et surtout non dépendante d'une application donnée. LeafletJS autait-il une méthode qui permette de lui fixer ces documents ? Ainsi je pourrait me passer de code maison pour gérer la liaison données brutes - style. D'autant que je génère déjà des fichiers MapCSS complets décrivant mon jeu de données destinés à JOSM. Merci par avance :) *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ dev-fr mailing list dev-fr@openstreetmap.org
Re: [OSM-dev-fr] Intégrer la date aux requêtes OAPI
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Newer Le 23 janvier 2014 19:02, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Bonsoir, Est-il possible d'intégrer la date d'édition des objets dans une requête OAPI ? Je me pose cette question, car utilisant aujourd'hui l'OAPI pour récupérer quelques objets (~200 pour l'instant), je vais bientôt importer des choses comme les pylônes et poteaux électriques tous les jours. Donc le jeu de retour sera de taille beaucoup plus importante, cependant un petit n'ombre de ces objets change quotidiennement. Vu qu'il n'y a pas de diff (et que je n'ai pas envie de processer les diffs standards), je me disais qu'utiliser la date d'édition pourrait réduire la quantité de données obtenue. Est-ce le bon raisonnement ? D'autres outils existent-ils ? Merci pour vos retours. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Intégrer la date aux requêtes OAPI
Super :) Merci, cet élément avait échappé à ma vigilance. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 23 janvier 2014 20:31, Christian Quest cqu...@openstreetmap.fr a écrit : http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Newer Le 23 janvier 2014 19:02, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Bonsoir, Est-il possible d'intégrer la date d'édition des objets dans une requête OAPI ? Je me pose cette question, car utilisant aujourd'hui l'OAPI pour récupérer quelques objets (~200 pour l'instant), je vais bientôt importer des choses comme les pylônes et poteaux électriques tous les jours. Donc le jeu de retour sera de taille beaucoup plus importante, cependant un petit n'ombre de ces objets change quotidiennement. Vu qu'il n'y a pas de diff (et que je n'ai pas envie de processer les diffs standards), je me disais qu'utiliser la date d'édition pourrait réduire la quantité de données obtenue. Est-ce le bon raisonnement ? D'autres outils existent-ils ? Merci pour vos retours. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] outil adresse du plugin JOSM cadastre-fr
Bonsoir, Je suis plutôt la même logique que Christian. Le jeudi 23 janvier 2014 14:01:04 Vincent de Château-Thierry a écrit : Je suis pour la 2e approche. Dans le cas d'une habitation sur une parcelle, avec une seule adresse associée, on ne peut pas mettre d'adresse sur l'emprise, vu qu'on ne trace pas les limites de parcelle dans OSM. Le bâtiment est alors la solution de repli, puisqu'il matérialise, indirectement, l'existence d'une propriété avec une adresse. Cas tordu : comment tu fais si il y a plusieurs bâtiments pour une même adresse (un même numéro), chacun de ces bâtiments ayant une entrée pour un logement individuel, mais les boîtes aux lettres rassemblées sous un même numéro ? (j'aime les cas tordus) -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
