Re: [OSM-talk-fr] Numéro de rue ?
Je ne met des adresses sur les polygones que pour les bâtiments éloignés de la rue, par exemple dans une résidence avec plusieurs immeubles où le cadastre met justement un numéro au milieu du bâtiment et pas sur l'entrée. +1, sauf si une ruelle ou une allée mène au bâtiment :) Cordialement, -- Mikaël Cordon, mickey86 Le 3 janvier 2013 23:35, Christian Quest cqu...@openstreetmap.fr a écrit : Le 3 janvier 2013 22:14, Cyrille Giquello cyrill...@gmail.com a écrit : Je viens appuyer l'explication de Romain. Mettre le numéro de la rue au plus près de l'entrée du lieu et non pas sur le bâti. C'est plus facile à trouver et plus simple à mapper, surtout quand il y a plusieurs bâtiments pour la même adresse, ou que le bâti se trouve loin de l'entrée, ou ... Et ça évite des questions existentielles lorsqu'il y a plusieurs bâtiments à la même adresse... Je ne met des adresses sur les polygones que pour les bâtiments éloignés de la rue, par exemple dans une résidence avec plusieurs immeubles où le cadastre met justement un numéro au milieu du bâtiment et pas sur l'entrée. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Le 4 janvier 2013 09:16, Mikaël Cordon mikael.cor...@gmail.com a écrit : Je ne met des adresses sur les polygones que pour les bâtiments éloignés de la rue, par exemple dans une résidence avec plusieurs immeubles où le cadastre met justement un numéro au milieu du bâtiment et pas sur l'entrée. +1, sauf si une ruelle ou une allée mène au bâtiment :) Oui. En fait, c'est par manque d'info, que je met le numéro sur le bâtiment lui même. Si le cadastre permet de déterminer où se trouve l'entrée (présence d'un chemin pour y accéder par exemple), ou si je l'ai relevé sur le terrain, alors là je met le numéro sur un noeud. Il y a juste un truc qui manque dans l'utilitaire adresses du plugin cadastre, c'est un raccourci pour gérer directement les bis/ter (par exemple shift+ctrl) sinon ça va super vite, même si ça prend du temps. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Le 4 janvier 2013 08:47, Christian Quest cqu...@openstreetmap.fr a écrit : Oui. En fait, c'est par manque d'info, que je met le numéro sur le bâtiment lui même. Si le cadastre permet de déterminer où se trouve l'entrée (présence d'un chemin pour y accéder par exemple), ou si je l'ai relevé sur le terrain, alors là je met le numéro sur un noeud. +1, c'est exactement ce que je fais Cela dit, depuis que je suis en Angleterre je n'ai pas réussi à convaincre les contributeurs locaux du bien-fondé de ma démarche (et en plus je me fait limite engueuler ^^). En fait ils sont tous d'accord pour n'assigner l’adresse qu'au batiment et jamais sur un node. (ex http://www.openstreetmap.org/?lat=52.48542lon=-1.91133zoom=17layers=M) -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Dans ce cas, comment gèrent-ils les bâtiments longs à plusieurs entrées ?!? Francescu Le 4 janvier 2013 10:12, Florian LAINEZ winner...@free.fr a écrit : Le 4 janvier 2013 08:47, Christian Quest cqu...@openstreetmap.fr a écrit : Oui. En fait, c'est par manque d'info, que je met le numéro sur le bâtiment lui même. Si le cadastre permet de déterminer où se trouve l'entrée (présence d'un chemin pour y accéder par exemple), ou si je l'ai relevé sur le terrain, alors là je met le numéro sur un noeud. +1, c'est exactement ce que je fais Cela dit, depuis que je suis en Angleterre je n'ai pas réussi à convaincre les contributeurs locaux du bien-fondé de ma démarche (et en plus je me fait limite engueuler ^^). En fait ils sont tous d'accord pour n'assigner l’adresse qu'au batiment et jamais sur un node. (ex http://www.openstreetmap.org/?lat=52.48542lon=-1.91133zoom=17layers=M) -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] (sans objet)
bonjour mon est Odette je suis sénégalaise je à Dakar je viens de connaitre openstreetmap et pour mieux comment sa se présente je me suis inscrite sur votre liste. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Bonjour, De : Francescu GAROBY Dans ce cas, comment gèrent-ils les bâtiments longs à plusieurs entrées ?!? Le 4 janvier 2013 10:12, Florian LAINEZ a écrit : Le 4 janvier 2013 08:47, Christian Quest a écrit : Oui. En fait, c'est par manque d'info, que je met le numéro sur le bâtiment lui même. Si le cadastre permet de déterminer où se trouve l'entrée (présence d'un chemin pour y accéder par exemple), ou si je l'ai relevé sur le terrain, alors là je met le numéro sur un noeud. +1, c'est exactement ce que je fais Cela dit, depuis que je suis en Angleterre je n'ai pas réussi à convaincre les contributeurs locaux du bien-fondé de ma démarche (et en plus je me fait limite engueuler ^^). En fait ils sont tous d'accord pour n'assigner l’adresse qu'au batiment et jamais sur un node. (ex http://www.openstreetmap.org/?lat=52.48542lon=-1.91133zoom=17layers=M) De mon côté (et pas en Angleterre :-) ) je place le(s) numero(s) toujours sur le bâtiment, avec une règle simple : si 1 seul numéro = placé comme attribut du way building, si plusieurs numeros : placés comme nodes du way building. Ce qui permet parfois des séquences ou s'intercalent n° d'adresse et POIs (shop, amenity) le long d'une façade. Illustration ici : http://osm.org/go/0BPGzaVuP-- vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
De mon côté (et pas en Angleterre :-) ) je place le(s) numero(s) toujours sur le bâtiment, avec une règle simple : si 1 seul numéro = placé comme attribut du way building, si plusieurs numeros : placés comme nodes du way building. Ce qui permet parfois des séquences ou s'intercalent n° d'adresse et POIs (shop, amenity) le long d'une façade. Illustration ici : http://osm.org/go/0BPGzaVuP-- vincent J'aime bien le rendu, cela permet d'un simple coup d'œil de savoir si il y a plusieurs adresse pour le même bâtiment par contre cela demande un petit ajustement du coté édition. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
C'est normal, tous ces immeubles avec le même numéro 6 ? Ça doit être un beau bordel pour le facteur surtout si ce sont des immeubles avec beaucoup de logements... Francescu Le 4 janvier 2013 10:26, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Francescu GAROBY Dans ce cas, comment gèrent-ils les bâtiments longs à plusieurs entrées ?!? Le 4 janvier 2013 10:12, Florian LAINEZ a écrit : Le 4 janvier 2013 08:47, Christian Quest a écrit : Oui. En fait, c'est par manque d'info, que je met le numéro sur le bâtiment lui même. Si le cadastre permet de déterminer où se trouve l'entrée (présence d'un chemin pour y accéder par exemple), ou si je l'ai relevé sur le terrain, alors là je met le numéro sur un noeud. +1, c'est exactement ce que je fais Cela dit, depuis que je suis en Angleterre je n'ai pas réussi à convaincre les contributeurs locaux du bien-fondé de ma démarche (et en plus je me fait limite engueuler ^^). En fait ils sont tous d'accord pour n'assigner l’adresse qu'au batiment et jamais sur un node. (ex http://www.openstreetmap.org/?lat=52.48542lon=-1.91133zoom=17layers=M) De mon côté (et pas en Angleterre :-) ) je place le(s) numero(s) toujours sur le bâtiment, avec une règle simple : si 1 seul numéro = placé comme attribut du way building, si plusieurs numeros : placés comme nodes du way building. Ce qui permet parfois des séquences ou s'intercalent n° d'adresse et POIs (shop, amenity) le long d'une façade. Illustration ici : http://osm.org/go/0BPGzaVuP-- vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
De : Francescu GAROBY C'est normal, tous ces immeubles avec le même numéro 6 ? Ça doit être un beau bordel pour le facteur surtout si ce sont des immeubles avec beaucoup de logements... Disons que je trouvais ça normal quand je l'ai fait (ça date un peu, 2010). Est-ce que je le ferais de la même manière aujourd'hui ? Je pense que oui, en considérant que le n°6 est le numero de toute la résidence, donc que, par exemple, pour envoyer un courrier à une personne habitant là, je marquerais sur l'enveloppe 6 avenue de Villiers, quel que soit le bâtiment. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Dans ce cas, je préfère avoir un polygone englobant (landuse=residential), qui lui portera le numéro ainsi que le nom de la résidence. Cela correspond mieux à la réalité, le numéro/nom n'est plus attaché à un bâtiment, mais à une zone entière. C'est aussi plus logique sur le plan données, car j'aime par trop avoir plusieurs objets en base pour décrire une seule chose (l'adresse, la résidence), ça me semble faciliter la réutilisation. Le 4 janvier 2013 10:41, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Francescu GAROBY C'est normal, tous ces immeubles avec le même numéro 6 ? Ça doit être un beau bordel pour le facteur surtout si ce sont des immeubles avec beaucoup de logements... Disons que je trouvais ça normal quand je l'ai fait (ça date un peu, 2010). Est-ce que je le ferais de la même manière aujourd'hui ? Je pense que oui, en considérant que le n°6 est le numero de toute la résidence, donc que, par exemple, pour envoyer un courrier à une personne habitant là, je marquerais sur l'enveloppe 6 avenue de Villiers, quel que soit le bâtiment. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Il doit y avoir un numéro/lettre de bâtiment ou d'entrée en plus du numéro dans la rue pour la résidence entière. A défaut, il y a une numérotation des appartements. Ce n'est probablement pas une anomalie. Le facteur peut s'y retrouver... Seul moyen : aller voir sur place les boites aux lettres et les plaques aux entrées. Le 4 janvier 2013 10:41, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Francescu GAROBY C'est normal, tous ces immeubles avec le même numéro 6 ? Ça doit être un beau bordel pour le facteur surtout si ce sont des immeubles avec beaucoup de logements... Disons que je trouvais ça normal quand je l'ai fait (ça date un peu, 2010). Est-ce que je le ferais de la même manière aujourd'hui ? Je pense que oui, en considérant que le n°6 est le numero de toute la résidence, donc que, par exemple, pour envoyer un courrier à une personne habitant là, je marquerais sur l'enveloppe 6 avenue de Villiers, quel que soit le bâtiment. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
De : Christian Quest Dans ce cas, je préfère avoir un polygone englobant (landuse=residential), qui lui portera le numéro ainsi que le nom de la résidence. Cela correspond mieux à la réalité, le numéro/nom n'est plus attaché à un bâtiment, mais à une zone entière. C'est aussi plus logique sur le plan données, car j'aime par trop avoir plusieurs objets en base pour décrire une seule chose (l'adresse, la résidence), ça me semble faciliter la réutilisation. Oui ça se tient, mais (hélas !) je n'ai jamais trouvé de modélisation satisfaisante pour la notion de résidence. C'est un de nos marronniers ici, d'ailleurs... :-) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
De : Philippe Verdy Il doit y avoir un numéro/lettre de bâtiment ou d'entrée en plus du numéro dans la rue pour la résidence entière. A défaut, il y a une numérotation des appartements. Ce n'est probablement pas une anomalie. Le facteur peut s'y retrouver... Oui, il y a une lettre par entrée (une entrée = une cage d'escalier). Les lettres sont dans des tags note=*, mais mériteraient d'aller sur un tag ref, collé à un node building=entrance. vincent. Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Ah oui, tien, je n'avais pas vu cet outil ! Je viens de le tester toujours ici : http://www.openstreetmap.org/?lat=49.390146lon=4.656073zoom=18layers=M Cependant, je sais (enfin, j'ai cru comprendre...) qu'on ne taggue pas pour le rendu, mais c'est plus joli sur lorsque les numéros sont sur les polygones. Comme ça, je trouve que ça fait plus fouilli, non ? En tout cas, de cette manière, OSM reconnaît bien les adresses. :) Il te suffit d'utiliser l'outil d'aide pour l'adresse du greffon cadastre pour créer très facilement les relations associatedStreet. Perso, j'ai pris pour habitude de mettre les numéros non pas sur l'ensemble du polygone mais sur un nœud soit solidaire sur un côté du polygone soit isolé de façon à matérialiser l'emplacement de la boite aux lettres. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Le 4 janvier 2013 11:13, Xavier x.larc...@laposte.net a écrit : Comme ça, je trouve que ça fait plus fouilli, non ? Je suis d'avis contraire. Au moins maintenant les numéros sont alignés. Alors que là où les numéros sont sur des polygones, c'est difficile de s'y retrouver ex: http://osm.org/go/0DEtdtMWl-- Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Ha oui en effet... Le 4 janvier 2013 11:17, Romain MEHUT romain.me...@gmail.com a écrit : Le 4 janvier 2013 11:13, Xavier x.larc...@laposte.net a écrit : Comme ça, je trouve que ça fait plus fouilli, non ? Je suis d'avis contraire. Au moins maintenant les numéros sont alignés. Alors que là où les numéros sont sur des polygones, c'est difficile de s'y retrouver ex: http://osm.org/go/0DEtdtMWl-- Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Finalement , oui, je plussoie. Et, est-ce que tout le monde sur cette liste s'accorde à dire que la solution est bonne ? Acceptable ? Auquel cas, peut être qu'un petit tuto dans le wiki serait utile. Histoire de formaliser. À moins qu'il n'existe déjà, mais je ne l'ai pas trouvé. Xavier Le 4 janvier 2013 11:13, Xavier x.larc...@laposte.net mailto:x.larc...@laposte.net a écrit : Comme ça, je trouve que ça fait plus fouilli, non ? Je suis d'avis contraire. Au moins maintenant les numéros sont alignés. Alors que là où les numéros sont sur des polygones, c'est difficile de s'y retrouver ex: http://osm.org/go/0DEtdtMWl-- Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
En voulant mettre à jour/corriger des limites d'EPCI, je tombe sur des tags addr:* mis dans la relation de ces EPCI. Ces tags semblent indiquer l'adresse des bureaux de l'EPCI... et ça me semble être une très mauvaise idée de l'indiquer de la sorte. Mettre un tag addr:* sur un objet c'est indiquer que cet objet décrit l'adresse... or addr:city mis sur l'emprise de l'EPCI est forcément faux. Si on veut indiquer l'emplacement des bureaux, ça devrait se faire par un membre particulier de la relation, pas par les tags, non ? Comment un algo qui va digérer ces données peut comprendre que non, pour une fois, ces tags addr:* ne servent pas à indiquer où se trouve une adresse ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] (sans objet)
Bienvenue Odette, ismaila sénégalais étudiant à Saint-Louis. Envoyé à partir de mon Windows Phone -- De : aida odette Envoyé : 04/01/2013 09:23 À : talk-fr@openstreetmap.org Objet : [OSM-talk-fr] (sans objet) bonjour mon est Odette je suis sénégalaise je à Dakar je viens de connaitre openstreetmap et pour mieux comment sa se présente je me suis inscrite sur votre liste. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Qu'est-ce qui empêche de positionner un noeud admin_centre dans une relation d'EPCI, ce noeud portant alors l'adresse de l'hôtel de communauté ou d'agglomération ? Cependant je ne suis pas sûr que les EPCI ont toutes un site administratif central, ce pourrait très bien être une réunion qui se passe alternativement dans les locaux des mairies des communes membres. Pour le courrier ce peut n'être qu'une boite postale, pour le téléphone un numéro non géographique, quand au site web il peut être hébergé n'importe où et géré par une société hors de l'EPCI avec un accès intranet pour les mairies membres via l'Internet. Et avec des points d'accueil directement dans chaque mairie. Et selon les services on aura une série d'adresses (par exemple des adresses différentes pour les services liés au logement, à l'aide sociale, pour les marchés publics, les inscriptions pour les écoles se feront suivant la carte scolaire dans les établissements, les ordures ménagères, l'eau et l'assainissement, les transports publics, la voirie et les espaces verts seront gérés encore ailleurs... Quant aux services administratifs internes, ils peuvent être n'importe où mais pas à disposition directe du public, qui passe par les mairies membres. Le conseil communautaire peut aussi se réunir de façon tournante dans une mairie ou une autre). Le 4 janvier 2013 11:45, Christian Quest cqu...@openstreetmap.fr a écrit : En voulant mettre à jour/corriger des limites d'EPCI, je tombe sur des tags addr:* mis dans la relation de ces EPCI. Ces tags semblent indiquer l'adresse des bureaux de l'EPCI... et ça me semble être une très mauvaise idée de l'indiquer de la sorte. Mettre un tag addr:* sur un objet c'est indiquer que cet objet décrit l'adresse... or addr:city mis sur l'emprise de l'EPCI est forcément faux. Si on veut indiquer l'emplacement des bureaux, ça devrait se faire par un membre particulier de la relation, pas par les tags, non ? Comment un algo qui va digérer ces données peut comprendre que non, pour une fois, ces tags addr:* ne servent pas à indiquer où se trouve une adresse ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
Résultat des courses sur Paray-le-Monial : c'est tout simplement bluffant : en quelques heures un progression fulgurante. Voici quelques emprises parlantes : vue générale http://www.openstreetmap.org/?lat=46.4511lon=4.1182zoom=14layers=M centre ville http://www.openstreetmap.org/?lat=46.451484lon=4.12149zoom=18layers=M parc d'activités http://www.openstreetmap.org/?lat=46.46563lon=4.11188zoom=16layers=M Il reste un complément à faire sur les repères majeurs : équipements, activités économiques clés, complément sur le nom des rues et adressage. Bravo à tous et bon week-end... Jean-Louis Nicolas Moyroud wrote Le 03/01/2013 20:11, ZIMMY a écrit : Merci Nicolas de ton aide précieuse. Je reprendrai là où il y aura des trous. Avec plaisir. Je me suis bien amusé ce soir malgré quelques inévitables petits conflits quand on bosse à plusieurs sur la même zone. Je crois qu'il ne va pas rester beaucoup de trous à combler dans les noms de rues. ;-) Maintenant, au lit... :-) a+ Nicolas ___ Talk-fr mailing list Talk-fr@ http://lists.openstreetmap.org/listinfo/talk-fr - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/Paray-le-Monial-une-commune-qui-risque-d-utiliser-OSM-pour-son-plan-de-ville-tp5742488p5742699.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Le 4 janvier 2013 12:00, Philippe Verdy verd...@wanadoo.fr a écrit : Qu'est-ce qui empêche de positionner un noeud admin_centre dans une relation d'EPCI, ce noeud portant alors l'adresse de l'hôtel de communauté ou d'agglomération ? Oui, un noeud de ce type me semble une bien meilleure solution qui ne crée par d'info ambigüe ! -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Affichage - Limites communales
Le message suivant de : ## Bonjour, Voici près d'un mois que nous avons terminé le travail de traçage et de renseignement des limites communales du département de l'Ardèche (pour rappel : [url]http://openstreetmap.fr/ardeche-master-sig-st-etienne[/url]). Cependant, celles-ci ne s'affichent toujours pas à une certaine échelle alors que les limites communales des communes anciennement tracées s'affichent (voir fichier joint). Savez-vous s'il y a une raison à cela? Merci par avance. Master 2 SIG Saint-Étienne a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=6 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Figurer le siège d'un EPCI (était : Numéro de rue ?)
De : Christian Quest Le 4 janvier 2013 12:00, Philippe Verdy a écrit : Qu'est-ce qui empêche de positionner un noeud admin_centre dans une relation d'EPCI, ce noeud portant alors l'adresse de l'hôtel de communauté ou d'agglomération ? Oui, un noeud de ce type me semble une bien meilleure solution qui ne crée par d'info ambigüe ! Par analogie, le rôle admin_centre dans une relation départementale pointe vers le node place de la localité chef-lieu du département, pas vers les bâtiments de la préfecture. Du coup s'il devait y avoir un rôle admin_centre, pour moi il devrait pointer vers le node place=* correspondant à l'admin_centre de la commune hébergeant le siège de l'EPCI. Mais je ne suis pas pour, car dans les faits je n'ai pas l'impression qu'on a une 'capitale', un 'chef-lieu' d'EPCI. En revanche s'il s'agit de pointer directement vers un bâtiment à l'adresse du siège, je verrais plutôt un rôle 'office', ou 'headquarter' (= 'siège'), inclus dans la relation boundary, et s'appuyant sur un node ou way ayant les attributs qui vont bien : building ,addr:housenumber, addr:street, name. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] problème overpass-api et area-query sur une relation
De : Pierre Béland Tu dis Les areas sont définis avec des critères en dur auxquels la relation en question ne correspond pas ... dommage. puisque tu sembles comprendre ce charabia, tu nous traduit en termes plus clairs,pour nous éviter de faire trop de boucles inutiles? L'overpass API considère comme surfaces (Areas) uniquement certains types de polygones. Le polygone de l'agglo de Tours est défini principalement par le tag 'boundary', tag reconnu, mais avec la valeur 'local_authority', qui ne fait pas partie des valeurs reconnues. Pour changer ça, il faudrait un peu de lobbying auprès du concepteur de l'Overpass-API. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] (sans objet)
Le 4 janvier 2013 12:07, ba aly luned...@gmail.com a écrit : bonjour je suis du cre de thies et j'aimerai avoir les données pour la région de thies. Bonjour, Comme la zone n'est pas trop grande ni chargée en données, le plus simple est d'afficher la zone à récupérer http://osm.org/go/axuqawK Et d'utiliser l'onglet Exporter - Données XML d'OpenStreetMap. Tu obtiendras un fichier au format OSM. Si tu souhaites récupérer shapefile plus connu des logiciels GIS il y a OSM2GIS http://www.osm974.re/osm2gis/ A+ Bruno ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Figurer le siège d'un EPCI (était : Numéro de rue ?)
Par analogie, le rôle admin_centre dans une relation départementale pointe vers le node place de la localité chef-lieu du département, pas vers les bâtiments de la préfecture. La dernière fois que j'ai regardé pour quelques départements et régions, c'était loin d'être le cas et on trouvait un peu de tout, y compris les bâtiments de la préfecture. Faudrait peut-être qu'on s'accorde à ce niveau là avant de passer aux EPCI. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Figurer le siège d'un EPCI (était : Numéro de rue ?)
Sauf que admin_centre ne signifie pas réellement chef-lieu ou capitale mais bien centre administratif, ce qui est tout à fait approprié. Maintenant on a le problème que admin_centre est majoritairement utilisé pour désigner un seul noeud, alors que même la notion de capitale ou de chef-lieu ne désigne PAS un noeud, et en tout cas PAS celui de la mairie, SAUF dans les communes. Le cas de Paris est édifiant : la capitale de la France n'est PAS le nœud positionné à l'Hôtel de Ville mais bien la TOTALITE de la ville de Paris (le département 75 en entier). Pour moi admin_centre devrait pointer réellement sur le nœud du siège administratif (et dans une même ville il y a souvent plusieurs sièges : la mairie (siège de la commune, ce nœud pouvant avoir un nom différent de celui de la commune, on devrait pouvoir directement utiliser un nœud nommé Mairie ou Hôtel de Ville sans rien d'autre en précision), l'Hôtel du conseil général (pour le département), l'Hôtel de région (pour la région). On a aussi une autre structure (hors collectivité locale) pour les préfectures et sous-préfectures (qui mériteraient aussi d'avoir dans les régions, départements et arrondissements, un autre nœud pointant vers la préfecture ou sous-préfecture). Un canton a bien un chef-lieu aussi, mais pas d'autre siège que la mairie désignée pour gérer les services du canton au nom de l'Etat (c'est un service délégué par la préfecture ou sous-préfecture). Ensuite que reste-t-il ? Des noeuds place qui n'ont pas à être sur le POI de la mairie, mais je me demande quelle est la pertinence de ces noeuds qui ne sont rien d'autre que des membres de type label (pour les communes). Et tous les chef-lieux ou capitales devraient indiquer la relation de la commune entière dans un rôle capital (inutile de désigner un point précis dans la commune). Bref pour moi on devrtait avoir dans les relations : - un rôle capital référençant la relation de la commune capitale/chef-lieu dans toutes les relations de niveau 2 à 7. - un rôle admin_center référençant le lieu (noeud ou polygone ou relation multipolygone) du siège administratif propre à chaque entité. Ce lieu n'est une mairie QUE dans les communes, il est une mairie d'arrondissement pour les arrondissements de commune ; sinon c'est l'hôtel de département (dans une relation niveau 6) ou de région (dans une relation niveau 4) ; sinon pour un EPCI c'est l'hôtel d'agglomération ou de communauté (là encore nœud, ou polygone ou multipolygone) ; sinon la France elle-même n'a pas d'admin_center unique (Est-ce l'Elysée, une des deux assemblées parlementaires, ou le Conseil Constitutionnel, ou le siège du Premier ministre ? Difficile de décider.) - un rôle comme state_center pour les préfectures ou sous-préfectures (de région, département ou d'arrondissement départemental) pointant sur un noeud, ou un chemin polygone ou une relation multipolygone autour des bâtiments du siège de la (sous-)préfecture. Les noeuds place=* sont là pour compatibilité (pour remplacer le polygone par un seul point bien positionné permettant en faible niveau de zoom de positionner un symbole sur la carte quand les frontières ne sont pas affichées) mais ne servent que comme rôle label dans les communes (parce que le nœud admin_centre d'une commune pointera en fait sur la mairie (avec un autre nom, et peut être plus grand qu'un noeud et être un polygone, voire un multipolygone entourant tous les bâtiments administratifs de la commune ; si c'est un multipolygone, rien n'interdit encore d'ajouter en plus un noeud dedans pour positionner le POI pour l'adresse principale de la mairie, c'est-à-dire l'entrée de son point d'accueil public, mais il portera lui aussi le nom Mairie ou Hôtel de Ville et non le nom de la commune porté par le membre label qui sera un place=*). Je ne vois pas l'intérêt en revanche d'un headquarter. Que mettre pour les EPCI qui n'ont pas d'hôtel de communauté ou d'agglomération ou de métropole propre ? Dans ce cas, regarder l'adresse postale pour voir où on tombe : ce sera souvent une des mairies membres qui inclue un service pour gérer administrativement les affaires de la communauté, et là encore ce sera le noeud, ou le polygone ou multipolygone de cette mairie (qui restera libellé Mairie ou Hôtel de Ville) Le 4 janvier 2013 13:25, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Christian Quest Le 4 janvier 2013 12:00, Philippe Verdy a écrit : Qu'est-ce qui empêche de positionner un noeud admin_centre dans une relation d'EPCI, ce noeud portant alors l'adresse de l'hôtel de communauté ou d'agglomération ? Oui, un noeud de ce type me semble une bien meilleure solution qui ne crée par d'info ambigüe ! Par analogie, le rôle admin_centre dans une relation départementale pointe vers le node place de la localité chef-lieu du département, pas vers les bâtiments de la préfecture. Du coup s'il devait y avoir un rôle admin_centre, pour moi il devrait pointer vers le node place=* correspondant
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
Je n'ai pas vu le avant/après mais je pense que c'est intéressant. Par contre je me demande pourquoi le rendu standard fait que le nom de la commune apparaît plus petit que le nom du quartier « la villeuneuve » ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonne et heureuse année 2013
2013/1/4 Philippe Verdy verd...@wanadoo.fr: Je n'ai que trop de ces messages depuis n'importe quel site ou projet, cela ne rime à rien. lol C'est l'hôpital qui se moque de la charité :-) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] (sans objet)
2013/1/4 ismaila ndiaye hote...@gmail.com Bienvenue Odette, ismaila sénégalais étudiant à Saint-Louis. Et en passant, un gros bienvenue sur cette liste de diffusion à tous les francophones du monde entier. Et excusez-nous par avance si les discussions sont parfois un peu trop... franco-françaises ! Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] (sans objet)
Tu as oublié les non-francophones qui sont sur cette liste pour pratiquer leur français :-) (Je plaisantes) Jo 2013/1/4 Pieren pier...@gmail.com 2013/1/4 ismaila ndiaye hote...@gmail.com Bienvenue Odette, ismaila sénégalais étudiant à Saint-Louis. Et en passant, un gros bienvenue sur cette liste de diffusion à tous les francophones du monde entier. Et excusez-nous par avance si les discussions sont parfois un peu trop... franco-françaises ! Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
2013/1/4 Vincent de Chateau-Thierry v...@laposte.net: Oui, il y a une lettre par entrée (une entrée = une cage d'escalier). Les lettres sont dans des tags note=*, mais mériteraient d'aller sur un tag ref, collé à un node building=entrance. Personne n'a encore relevé cette remarque. Pour info, le préfixe addr: s'est agrandi depuis ses débuts pour supporter les adresses plus complexes. Il y a maintenant des addr:door, addr:flats, addr:floor ou addr:unit qui pourraient avantageusement se substituer à un note=* ou ref=* : http://wiki.openstreetmap.org/wiki/Addr Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonne et heureuse année 2013
Le 4 janvier 2013 14:27, Pieren pier...@gmail.com a écrit : 2013/1/4 Philippe Verdy verd...@wanadoo.fr: Je n'ai que trop de ces messages depuis n'importe quel site ou projet, cela ne rime à rien. lol C'est l'hôpital qui se moque de la charité :-) Oui mais ces messages n'ont rien à dire et se répètent les uns les autres. Une fois le premier reçu je pense que tout le monde le prend déjà pour soi. Mes vœux je les adresse à ma famille, en privé, et pas sur une liste à des personnes que je ne connais pas. En revanche c'est utile de glisser ça en deux mots s'il y a une info en plus (par exemple le message qui mentionne une vidéo d'animation des contributions de 2012, ou un compte-rendu de l'année, ou annonce un plan de travail pour 2013, ou un état des lieux de ce qui reste à faire avec des statistiques remises à jour). Mais envoyer un message juste pour les vœux c'est hors sujet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
Regarder comment a été renseigné la population pour la commune et son type place=*. Comparer au type place=* donné au quartier de La Villeneuve. Si ça se trouve le nœud de ce quartier est tagué en suburb, alors que la commune est taguée en village. En principe les suburbs sont plus gros que les villages et concernent les quartiers de grandes agglomérations. Note : place=village c'est pour toutes les communes de 100 à moins de 1 habitants (celles de moins de 100 habitants sont normalement taguées en place=hamlet mais là tout le monde n'estpas d'accord et on tient compte de la population historique qui a pu être très supérieure dans les petits villags ruraux qui gardent leur statut de village qui était le sien lorsque la commune a été créée. Certaines petites communes ont aussi des variations conséquentes et rapides de leur population (il suffit parfois d'un lotissement, ou d'une démolition d'une ancienne résidence, ou HLM, ou d'un fort exil lié au départ d'une entreprise locale, ou de l'implantation d'une entreprise pour que cela change considérablement ; la fermeture d'une caserne, d'un hôpital, d'une maison de retraite aussi, ou parfois le déménagement d'un centre pénitentiaire...). Bref vérifier les derniers chiffres de population sur le site de l'INSEE (au moins les chiffres de 2009 maintenant tous consolidés : penser à les corriger si cela n'a pas été fait car souvent les chiffres daans OSM sont très grossiers et carrément faux : personnellement je met le dernier chiffre exact donné par l'INSEE, sans aucun arrondi dans population=n et j'ajoute systématiquement population:date=2009 pour indiquer la date retenue par l'INSEE ; s'il y a des chiffres plus récents publiés par l'INSEE pour la population légale 2013, je mets en année non pas 2013 mais l'année de référence indiquée pour le calcul.) Je monte que l'INSEE envisage de mettre à jour OSM directement avec les derniers chiffres de population mais ce serait bien de se mettre d'accord sur le tag à utiliser pour indiquer l'année et/ou la source. Et à mon avis la population serait plutôt à mettre à jour dans la relation, même si on la copie aussi dans le noeud place=* indiqué en admin_center, afin de valider la valeur donnée en place=* (place=hamlet si population100, place=village si population1, place=city si population10, etc.) Pour les quartiers, je n'utilise pas suburb sauf pour les communes à arrondissements ou à grand quartiers administratifs. Pour les autres soit, on a plusieurs agglomérations et j'utilise place=village si on estime la population de chacune comme suffisante, sinon place=locality (pour les quartiers non clairement délimités), et autres place=isolated_dwelling pour les lieux-dits ruraux limités à une seule adresse (une ferme par exemple) sinon place=hamlet pour quelques adresses autour d'un même lieu non délimité officiellement (par exemple une ferme habitée et quelques maisons autour le long d'une route hors agglomération). Le 4 janvier 2013 14:20, Nolwenn donolw...@gmail.com a écrit : Je n'ai pas vu le avant/après mais je pense que c'est intéressant. Par contre je me demande pourquoi le rendu standard fait que le nom de la commune apparaît plus petit que le nom du quartier « la villeuneuve » ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation du réseau électrique français
Bonjour, Le 3 janvier 2013 23:04, Christian Quest cqu...@openstreetmap.fr a écrit : Pour la SNCF, il y a des relations route=train pour décrire les trains qui circulent sur les route=railway qui sont les infrastructures des lignes elles même. Les premiers sont liés à la SNCF, les seconds en réalité à RFF. C'est pertinent. Ici les route=railway sont donc nos circuits. Les ways qui en sont membres sont donc soit les voies physiques, soit les files de pylônes. François, ton TOC* est déjà identifié: les pylônes électrique car dans ces relations, il n'y a pas de pylônes... certaines lignes ferroviaires n'étant toujours pas électrifiées ;) Ah oui un TOC :) C'est surtout que je cherche à avoir une vue topologique du réseau. Mon réflexe était de représenter chaque circuit (ou chaque sens des voies ferrées doubles par exemple) mais c'est pas la manière la plus économique en temps et en taille de données. Je comprends un peu mieux maintenant. Les relations donnent la topologie, les ways le côté purement géographique et on a rarement besoin des deux en même temps. Une habitude qui vient des routes, l'une passe forcément sur l'autre et layer permet d'indiquer qui est dessus, qui est dessous ce qui n'est pas forcément sans intérêt, car dans la réalité c'est quand même bien comme ça. D'accord oui en effet. Une situation à laquelle j'ai été confronté hier soir en tentant de représenter l'intérieur d'un poste 400 kV RTE : les lignes arrivent sur des portiques puis chaque phase est raccordé sur le jeu de barre correspondant. http://wiki.openstreetmap.org/wiki/Power_lines#inside_power_stations Pour raccorder chaque ligne aux jeux de barres, je suis tenté d'utiliser une way power=cable entre le portique power=tower et le jeu de barre (way) power=busbar Le câble supporte une phase alors que le power=line en supporte n, selon le régime régional considéré. = Le tag cables=X sur les lignes haute-tension me semble superflu puisqu'on a systématiquement les mêmes configuration suivant le régime choisi. Ici le câble est bien connecté à une ligne sans pour autant qu'on se préoccupe du layer mais je n'ai peut-être pas considéré les bonnes hypothèses. Selon ces mêmes hypothèses, je trouve qu'utiliser un power=line + layer=XX dans le cas d'une ligne multi-phase est sémantiquement mieux qu'utiliser un power=cable qui reste trop éloigné de la vraie nature de l'équipement représenté. Pour rester sur le même thème, je pense être dans le vrai pour dire que ces câbles de phase connectés entre les portiques et les jeux de barres doivent faire partie des relations représentant les circuits avec role=Lx pour indiquer le numéro de phase (normalement déductible visuellement sur les transformateurs puis en remontant le jeu de barre). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Numéro de rue ?
Le 4 janvier 2013 14:44, Pieren pier...@gmail.com a écrit : Personne n'a encore relevé cette remarque. Pour info, le préfixe addr: s'est agrandi depuis ses débuts pour supporter les adresses plus complexes. Il y a maintenant des addr:door, addr:flats, addr:floor ou addr:unit qui pourraient avantageusement se substituer à un note=* ou ref=* : http://wiki.openstreetmap.org/wiki/Addr Et pour les numéros/lettres/noms de bâtiments dans les résidences ? Note que les bâtiments ou entrées n'ont pas toujours de numéro propre. Ce sont alors les numéros d'appartements qui servent à identifier les adresses (par exemple groupés par centaines : appartements 1 à 99 pour une des entrées, appartements 101 à 299 pour une autre ; les étages sont souvent indiqués par les dizaines). Il y a parfois plusieurs entrées pour les mêmes appartements, les numéros d'escaliers/ascenseur sont alors peu pertinents. Il faut donc s'adapter. Mais il faudrait donc avoir aussi addr:building=A, ou addr:building=Bâtiment Marie Curie (non restreint à un numéro ou une lettre) Dans certains cas, on a aussi des numéros de zones ou secteurs pour localiser les bâtiments, particulièrement dans les zones d'entreprises. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonne et heureuse année 2013
Le 4 janv. 2013 à 14:47, Philippe Verdy a écrit : Le 4 janvier 2013 14:27, Pieren pier...@gmail.com a écrit : 2013/1/4 Philippe Verdy verd...@wanadoo.fr: Je n'ai que trop de ces messages depuis n'importe quel site ou projet, cela ne rime à rien. lol C'est l'hôpital qui se moque de la charité :-) Mais envoyer un message juste pour les vœux c'est hors sujet. C'est moins fatiguant à lire que le HS dont personne ou presque ne lit en entier ou n'en retire pas grand-chose, car, on ne peut le lire qu'en diagonale. Je forme un voeu spécial pour toi : l'apprentissage de la sobriété dans l'expression. Ceci dit, j'ai préféré envoyer mes voeux sur la liste en préambule d'un message et cela me paraît plus efficace : on peux attendre quelques jours pour voir, si on n'aura pas quelque chose à communiquer. Christian Rogel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Bonjour, Je suis plutôt pour conserver un historique en effet. Par contre non pas l’implanter dans les tags, il est possible d'utiliser les versions. Ces dernières ont déjà une dimension temporelle, plus temporelle que les tags par exemple. Le problème est qu'on ne sait pour l'instant pas si le passage d'une version à l'autre reflète une modification de la carte uniquement ou une édition suite à une modification du terrain. Ca demande forcément quelques modifications de l'API et on peut facilement préciser dans une requête qu'on ne veut que des données contemporaines et pas du passé. C'est d'ailleurs étonnant que ca ne fasse pas partie des motivations de l'utilisation d'une base versionnée... 2013/1/3 Christian Quest cqu...@openstreetmap.fr Au moins l'avantage avec des données anciennes, c'est qu'elles sont stables ;) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *François Lacombe* *Apprenti Ingénieur Télécom Bretagne* francois dot lacombe At telecom-bretagne dot eu +33 6 73 41 92 99 http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Figurer le siège d'un EPCI (était : Numéro de rue ?)
De : Pieren 2013/1/4 Philippe Verdy : Le cas de Paris est édifiant : la capitale de la France n'est PAS le nœud positionné à l'Hôtel de Ville mais bien la TOTALITE de la ville de Paris (le département 75 en entier). Ben, si c'est le cas, c'est une erreur. L'idée de départ du rôle admin_centre était de lier les polygones boundary=administrative (qui étaient nouveaux) avec les noeuds place=* (plus anciens). La solution était élégante car elle fonctionnait pour tous les niveaux administratifs. Malheureusement, cela n'a pas empêché la création de doublons comme le tag capital=yes qui est plus simple à exploiter dans les logiciels consommateurs de données OSM (ça évite d'examiner toutes les relations auquel l'élément place appartient). Rien n'empêche d'utiliser ce rôle dans d'autres types de relations. Ou de lui donner un autre nom... Au passage, impossible de remettre la main dans le wiki sur une page décrivant l'intention du rôle admin_centre. J'ai l'impression que ta page de proposition a été effacée mais sans transfert du contenu ailleurs contrairement au commentaire ici : http://wiki.openstreetmap.org/wiki/Relations/Proposed/add_admin_centre_in_Relation:bounda ry vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Paray-le-Monial : une commune qui risque d'utiliser OSM pour son plan de ville
le 04/01/2013 14:42, Philippe Verdy a écrit: Regarder comment a été renseigné la population pour la commune et son type place=*. Comparer au type place=* donné au quartier de La Villeneuve. Si ça se trouve le nœud de ce quartier est tagué en suburb, alors que la commune est taguée en village. En principe les suburbs sont plus gros que les villages et concernent les quartiers de grandes agglomérations. Effectivement le tag était place=suburb Pour les quartiers, je n'utilise pas suburb sauf pour les communes à arrondissements ou à grand quartiers administratifs. Pour les autres soit, on a plusieurs agglomérations et j'utilise place=village si on estime la population de chacune comme suffisante, sinon place=locality (pour les quartiers non clairement délimités), et autres place=isolated_dwelling pour les lieux-dits ruraux limités à une seule adresse (une ferme par exemple) sinon place=hamlet pour quelques adresses autour d'un même lieu non délimité officiellement (par exemple une ferme habitée et quelques maisons autour le long d'une route hors agglomération). Tu oublies place=neighbourhood pour les quartiers. Je viens de le corriger ainsi. Samy ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] problème overpass-api et area-query sur une relation
Le 4 janvier 2013 13:34, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Pierre Béland Tu dis Les areas sont définis avec des critères en dur auxquels la relation en question ne correspond pas ... dommage. puisque tu sembles comprendre ce charabia, tu nous traduit en termes plus clairs,pour nous éviter de faire trop de boucles inutiles? L'overpass API considère comme surfaces (Areas) uniquement certains types de polygones. Le polygone de l'agglo de Tours est défini principalement par le tag 'boundary', tag reconnu, mais avec la valeur 'local_authority', qui ne fait pas partie des valeurs reconnues. Pour changer ça, il faudrait un peu de lobbying auprès du concepteur de l'Overpass-API. En fait la sélection des éléments pouvant servir de polygone area n'est pas dans le code source mais juste dans une requête exécutée régulièrement en tâche de fond (cf http://wiki.openstreetmap.org/wiki/Overpass_API/Areas). Donc ces règles de sélection sont propres à chaque instance de l'Overpass-API. Sly me disait que cette requête est très très gourmande en ressources et donc limitée à certains éléments pour qu'elle soit viable. Du coup, le lobbying, c'est auprès de Sly et de l'asso OSM-Fr qu'il faut le faire ;-) - Pour que Sly installe cette requête en tâche de fond. - Pour que l'Overpass-API soit sur une machine hyper-puissance ;-) Cyrille. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Les numéros de version ne s'appliquent qu'au données, pas à l'historique d'un objet sur le terrain. Le changement d'année apporte son lot de changement dans les découpages administratifs, les intercommunalités, etc. J'essaye de produire une carte où j'ai besoin des EPCI de 2010... comment je fais ? Prendre des données OSM de 2010 ? Loupé... il n'y avait quasiment aucun EPCI. Autant je comprend tout à fait qu'on ne peut pas tout mettre dans OSM et que faire des cartes historiques dépasse le cadre d'OSM avec son fonctionnement actuel autant certaines informations récentes mais ne correspondant plus au présent peuvent être bien utiles. C'est cette réflexion que j'essaye d'avoir. Le 4 janvier 2013 15:06, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Bonjour, Je suis plutôt pour conserver un historique en effet. Par contre non pas l’implanter dans les tags, il est possible d'utiliser les versions. Ces dernières ont déjà une dimension temporelle, plus temporelle que les tags par exemple. Le problème est qu'on ne sait pour l'instant pas si le passage d'une version à l'autre reflète une modification de la carte uniquement ou une édition suite à une modification du terrain. Ca demande forcément quelques modifications de l'API et on peut facilement préciser dans une requête qu'on ne veut que des données contemporaines et pas du passé. C'est d'ailleurs étonnant que ca ne fasse pas partie des motivations de l'utilisation d'une base versionnée... 2013/1/3 Christian Quest cqu...@openstreetmap.fr Au moins l'avantage avec des données anciennes, c'est qu'elles sont stables ;) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- François Lacombe Apprenti Ingénieur Télécom Bretagne francois dot lacombe At telecom-bretagne dot eu +33 6 73 41 92 99 http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Les versions d'objets ne sont pas satisfaisantes. Elles traitent toutes sortes de situations de modifications ou suppression/scission/fusions d'objets, parfois aussi des reverts, ou des modifs annulées ou rendues invisibles par un problème d'incompatibilité de licences ou de violation de droits. La date de ces modifications n'a rien à voir avec la validité historique de ces objets. On ne pourrait donc pas se passer des tags pour mentionner les fates de validité des données historiques. Quelque chose comme historic:start=-mm-dd et historic:end=-mm-dd. Mais on doit alors toruver un moyen clair de les cacher automatiquement et facilement pour un rendu actuel avec hidden=historic pour qu'il n'y ait pas de confusion avec les objets actuels. A mon avis ces données historiques devraient être clairement accessibles uniquement avec une requête spécifique qui les demande, et masquées automatiquement par l'API standard, sinon on n'évitera pas une base de données séparée, car ces données peuvent être très perturbantes pour plein d'outils. Il faudrait donc que l'API permette de faire non pas une suppression simple, mais permette de transformer un objet en objet historique, gardé par la base mais non accédé par défaut. L'autre problème à régler est l'intégrité référentielle (des membres de relation ou des noeuds de chamin) si on masque ces données historiques, et l'intégrité géométrique (si des noeuds ont été déplacés sans être effacés ou gardés à part dans l'historiques sous un ID différent, masqué par défaut). Tout cela mériterait une réflexion générale sur le schéma et sur la possibilité de le rendre compatible avec un déploiement employant des bases de données parallèles (pour ne pas surcharger trop non plus la base principale), et ne pas trop compliquer non plus le travail pour les nouveaux contributeurs qui seront tentés de supprimer des objets qui n'existent plus ou bien ne sont plus au même endroit. La solution des versions d'objets n'est pas adaptée à ces usages pour produire des cartes historiques. Je pense que cela devrait se faire dans une base d'un projet séparé. Ce sera bien quand les éditeurs sauront travailler sur plusieurs bases en même temps, dans des calques séparés (sans fusion possible de l'un vers l'autre, uniquement des copies d'une base vers l'autre mais pas nécessairement avec les mêmes id's, mais avec une possibilité d'un objet d'une base de référencer des objets d'une autre base via les ref:*=*). Le 4 janvier 2013 15:06, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Bonjour, Je suis plutôt pour conserver un historique en effet. Par contre non pas l’implanter dans les tags, il est possible d'utiliser les versions. Ces dernières ont déjà une dimension temporelle, plus temporelle que les tags par exemple. Le problème est qu'on ne sait pour l'instant pas si le passage d'une version à l'autre reflète une modification de la carte uniquement ou une édition suite à une modification du terrain. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] problème overpass-api et area-query sur une relation
Je ne sais pas si c'est cette requête pour maintenir les area à jour qui est lourde où si ce sont celles les utilisant ensuite sur l'overpass... C'est vrai aussi qu'à un moment passer à postgis offre un autre champ de possibilités, il faudrait ajouter un moyen de requêter postgis via HTTP pour une exploitation dans les slippymaps. Le 4 janvier 2013 15:26, Cyrille Giquello cyrill...@gmail.com a écrit : Le 4 janvier 2013 13:34, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Pierre Béland Tu dis Les areas sont définis avec des critères en dur auxquels la relation en question ne correspond pas ... dommage. puisque tu sembles comprendre ce charabia, tu nous traduit en termes plus clairs,pour nous éviter de faire trop de boucles inutiles? L'overpass API considère comme surfaces (Areas) uniquement certains types de polygones. Le polygone de l'agglo de Tours est défini principalement par le tag 'boundary', tag reconnu, mais avec la valeur 'local_authority', qui ne fait pas partie des valeurs reconnues. Pour changer ça, il faudrait un peu de lobbying auprès du concepteur de l'Overpass-API. En fait la sélection des éléments pouvant servir de polygone area n'est pas dans le code source mais juste dans une requête exécutée régulièrement en tâche de fond (cf http://wiki.openstreetmap.org/wiki/Overpass_API/Areas). Donc ces règles de sélection sont propres à chaque instance de l'Overpass-API. Sly me disait que cette requête est très très gourmande en ressources et donc limitée à certains éléments pour qu'elle soit viable. Du coup, le lobbying, c'est auprès de Sly et de l'asso OSM-Fr qu'il faut le faire ;-) - Pour que Sly installe cette requête en tâche de fond. - Pour que l'Overpass-API soit sur une machine hyper-puissance ;-) Cyrille. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
C'est l'utilisation de tags standards qui crée la confusion. Ajouter un tag (comme historic=yes) ne résoudra le problème que pour les outils tenant compte de celui-ci, ce n'est donc pas une bonne solution à mon avis. Le principe du suffixe aux tags ne vous semble pas intéressant à creuser ? Rappel: name[:1970]=Place de l'Etoile - pas de risque de confusion - possibilité d'en avoir plusieurs car des changements il peut y en avoir eu plus d'un ! -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] problème overpass-api et area-query sur une relation
Le 4 janvier 2013 15:33, Christian Quest cqu...@openstreetmap.fr a écrit : Je ne sais pas si c'est cette requête pour maintenir les area à jour qui est lourde où si ce sont celles les utilisant ensuite sur l'overpass... C'est surtout leur génération qui est lourde, me semble-t-il. C'est vrai aussi qu'à un moment passer à postgis offre un autre champ de possibilités, il faudrait ajouter un moyen de requêter postgis via HTTP pour une exploitation dans les slippymaps. Ça risque d'être encore plus chaud : très facile de saturer le serveur puisque l'on pourrait tout lui demander tout le temps. L'overpass-API c'est super bien: - un type de requêtes largement suffisant - une construction des données optimisées pour le type de requête - un service qui tient la route L'option de limite des requête sur un polygone est vraiment super, même si limitée à un type de données. Et en plus ce filtrage est négociable ;-) Cyrille. Le 4 janvier 2013 15:26, Cyrille Giquello cyrill...@gmail.com a écrit : Le 4 janvier 2013 13:34, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Pierre Béland Tu dis Les areas sont définis avec des critères en dur auxquels la relation en question ne correspond pas ... dommage. puisque tu sembles comprendre ce charabia, tu nous traduit en termes plus clairs,pour nous éviter de faire trop de boucles inutiles? L'overpass API considère comme surfaces (Areas) uniquement certains types de polygones. Le polygone de l'agglo de Tours est défini principalement par le tag 'boundary', tag reconnu, mais avec la valeur 'local_authority', qui ne fait pas partie des valeurs reconnues. Pour changer ça, il faudrait un peu de lobbying auprès du concepteur de l'Overpass-API. En fait la sélection des éléments pouvant servir de polygone area n'est pas dans le code source mais juste dans une requête exécutée régulièrement en tâche de fond (cf http://wiki.openstreetmap.org/wiki/Overpass_API/Areas). Donc ces règles de sélection sont propres à chaque instance de l'Overpass-API. Sly me disait que cette requête est très très gourmande en ressources et donc limitée à certains éléments pour qu'elle soit viable. Du coup, le lobbying, c'est auprès de Sly et de l'asso OSM-Fr qu'il faut le faire ;-) - Pour que Sly installe cette requête en tâche de fond. - Pour que l'Overpass-API soit sur une machine hyper-puissance ;-) Cyrille. vincent -- Cyrille. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Figurer le siège d'un EPCI (était : Numéro de rue ?)
Oui, un effacement franchement mal fait : la proposition aurait du être au moins intégrée aux discussions comme ici: http://wiki.openstreetmap.org/wiki/Talk:Relation:boundary#Label_role Il y a peut-être moyen de récupérer cela dans les archives car sur MediaWiki une suppression n'est pas un réel effacement mais un masquage, encore consultable par un admin du wiki. Les propositions même rejetées devraient être gardées, avec le statu mentionnant le rejet et les raisons. afin de pouvoir les réanalyser plus tard. Parfois des propositions sont faites trop tôt ou posent encore des problèmes de compatibilité, ou d'ambiguité avec l'existant, mais de nombreuses ambiguités disparaissent petit à petit, ou on trouve des règles pour les lever et des outils d'analyse développés pour traiter les derniers cas problématiques. Les façon de taguer évoluent, souvent on a des solutions simples quasi automatiques (certaines faites directement et silencieusement par les éditeurs comme JOSM). Osmose et OSMI ont permis d'en lver bon nombre et permis ensuite de faire évoluer le schéma, les moteurs de rendus, les éditeurs, et permis de nouveaux contrôles de cohérence et vérification des données, ou ont facilité l'utilisation des données d'OSM avec d'autres bases de données. Le 4 janvier 2013 15:18, Vincent de Chateau-Thierry v...@laposte.net a écrit : De : Pieren 2013/1/4 Philippe Verdy : Le cas de Paris est édifiant : la capitale de la France n'est PAS le nœud positionné à l'Hôtel de Ville mais bien la TOTALITE de la ville de Paris (le département 75 en entier). Ben, si c'est le cas, c'est une erreur. L'idée de départ du rôle admin_centre était de lier les polygones boundary=administrative (qui étaient nouveaux) avec les noeuds place=* (plus anciens). La solution était élégante car elle fonctionnait pour tous les niveaux administratifs. Malheureusement, cela n'a pas empêché la création de doublons comme le tag capital=yes qui est plus simple à exploiter dans les logiciels consommateurs de données OSM (ça évite d'examiner toutes les relations auquel l'élément place appartient). Rien n'empêche d'utiliser ce rôle dans d'autres types de relations. Ou de lui donner un autre nom... Au passage, impossible de remettre la main dans le wiki sur une page décrivant l'intention du rôle admin_centre. J'ai l'impression que ta page de proposition a été effacée mais sans transfert du contenu ailleurs contrairement au commentaire ici : http://wiki.openstreetmap.org/wiki/Relations/Proposed/add_admin_centre_in_Relation:bounda ry vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Figurer le siège d'un EPCI (était : Numéro de rue ?)
Il me semble qu'il y a eu fusion en partie vers http://wiki.openstreetmap.org/wiki/Relations/Proposed/Region mais que cette proposition aussi a été abandonnée (mais la page wiki a tout de même été conservée ! Le 4 janvier 2013 15:18, Vincent de Chateau-Thierry v...@laposte.net a écrit : Au passage, impossible de remettre la main dans le wiki sur une page décrivant l'intention du rôle admin_centre. J'ai l'impression que ta page de proposition a été effacée mais sans transfert du contenu ailleurs contrairement au commentaire ici : http://wiki.openstreetmap.org/wiki/Relations/Proposed/add_admin_centre_in_Relation:boundary Bref on est dans le flou total maintenant concernant les admin_centre ! Là où c'est cohérent en revanche c'est en Belgique et en Espagne (ce dernier utilise aussi le tag capital=*). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Le fait que ça n'ai pas été intégré dès le départ va forcément motiver pas mal de modifications. Profitons-en. Les versions correspondent peut-être à diverses modifications qui ne relève pas d'un changement terrain, mais lorsqu'il y a changement terrain, il y a une nouvelle version OSM et c'est ce qui compte. Pour l'avoir déjà testé, un fonctionnement à 4 dates permet : - de dater la version elle-même - de dater l'objet qu'elle représente de manière différente (ces dates peuvent ne pas évoluer d'une version à l'autre). Utiliser les tags, même avec un suffixe, va compliquer les choses si on veut des enregistrements sans les données historisées. Les tags ne sont pas les seuls à être modifiés, les coordonnées d'un node (par exemple) le peuvent également d’où l'impérieuse nécessité :) de placer l'historisation au niveau de l'enregistrement (sa version). Les tags restent un tableau à 2 dimensions, c'est peu évolutif comme concept, la version l'est beaucoup plus. Pour le soucis des liaisons, ça ne sera pas simple dans tous les cas. - Si on utilise un identifiant invariant suivant la version (comme c'est le cas sur OSM), l'intégrité n'est pas préservée. - Si on utilise un identifiant unique par couple objet/version, chaque mise à jour d'objet va être un casse-tête pour le répliquer dans les références qui le pointent. Je crois que c'est un thème abordé sur le Wiki de débat sur l'API 0.7 par ailleurs. Le 4 janvier 2013 15:38, Christian Quest cqu...@openstreetmap.fr a écrit : C'est l'utilisation de tags standards qui crée la confusion. Ajouter un tag (comme historic=yes) ne résoudra le problème que pour les outils tenant compte de celui-ci, ce n'est donc pas une bonne solution à mon avis. Le principe du suffixe aux tags ne vous semble pas intéressant à creuser ? Rappel: name[:1970]=Place de l'Etoile - pas de risque de confusion - possibilité d'en avoir plusieurs car des changements il peut y en avoir eu plus d'un ! -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *François Lacombe* *Apprenti Ingénieur Télécom Bretagne* francois dot lacombe At telecom-bretagne dot eu +33 6 73 41 92 99 http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Le 4 janvier 2013 15:38, Christian Quest cqu...@openstreetmap.fr a écrit : C'est l'utilisation de tags standards qui crée la confusion. Ajouter un tag (comme historic=yes) ne résoudra le problème que pour les outils tenant compte de celui-ci, ce n'est donc pas une bonne solution à mon avis. Le principe du suffixe aux tags ne vous semble pas intéressant à creuser ? Rappel: name[:1970]=Place de l'Etoile Cela ne marche QUE pour les objets dont la géométrie n'a pas évolué. Là je parlais des objets limités différemment (par exemples des fusions/scissions de cmmunes ou d'EPCI ou d'arrondissements, ou changements du découpage cantonal/électoral, voire aussi les anciens pays comme la Tchécoslavquie, ou l'Union soviétique, ou la RDA, font il est aberrant de ne plus pouvoir dresser une carte alors qu'on a souvent besoin de les montrer pour expliquer l'histoire, ou encore les variations des frontières de la France au cours des siècles, y compris les départements d'Alsace et Lorraine pendant les conflits avec l'Allemagne depuis 1870, ou encore les cartes des anciens empires français et britanniques). Pourtant l'histoire a fourni des traces persistantes dans les statuts légaux et traités internationaux (par exemple en Alsace-Moselle pour le concordat), qu'il est difficile de matérialiser sans support par une carte montrant ces historiques. Il y a aussi le cas des collectivités en transition (deux coexistent dans la même période : il n'est pas toujours poassible de choisir l'une ou l'autre comme plus actuelle, même si leurs tags sont différents) : on a donc besoin d'objets séparés marqués entièrement eux-mêmes comme historiques avec leur propre ID séparé des objets actuels. Et pouvoir disposer d'un filtre permettant de masquer AUTOMATIQUEMENT certains objets historiques (tant qu'on ne les demande pas EXPLICITEMENT dans une requête) serait préférable à l'introduction de tags spéciaux comme name[:1970] : à mon avis c'est mieux de coder deux objets séparés chacun avec leur date de validité et la possibilité d'en cacher certains par défaut. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSMTransport France
Bonjour, OSMTransport est un démonstrateur, mais tout de même bien pratique ;-) Du coup, les données ne semblent pas très fraiches, est-ce intentionnel ou juste une panne ? Si le rafraichissement est prévu, quelle est sa fréquence ? Merci Cyrille. Le 17 octobre 2012 17:58, rldhont rldh...@gmail.com a écrit : Le 17/10/2012 14:05, Guilhem Bonnefille a écrit : Le 16 octobre 2012 17:42, Otourly Wiki otou...@yahoo.fr a écrit : Je sais pas où remonter les erreurs d'OSM transport mais le funiculaire de Lyon qui va à Saint-Just s'arrête à l'arrêt Saint-Just. La base et le rendu OSM est juste... Interrogation similaire : j'ai remarqué une incomplétude. J'ai voulu corriger dans OSM mais... je trouve moins d'information dans OSM que dans OSM transport. A quoi est-ce dû ? Vous utilisez quelles données ? Les données n'étaient peut-être pas très fraîche... PS : ce bug est en région Toulousaine J'ai mis à jour Toulouse René-Luc ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Le 4 janvier 2013 15:38, Christian Quest cqu...@openstreetmap.fr a écrit : Rappel: name[:1970]=Place de l'Etoile Malheureusement les dates sont un des nids à problèmes de l'informatique et, à ma connaissance, il n'existe pas de solution universelle. Surtout que ta proposition suppose que ce soit une plage de dates, et non une date seule, qui indexe le nom. Car j'imagine que tu vas vouloir dire quel était le nom de cette place en 1969, un jour. Ce n'est pas impossible, mais je ne sens absolument pas OSM assez robuste pour ça. Surtout que, sauf erreur, le name n'est qu'un tag parmi d'autres, qui ne distingue absolument pas l'objet terrain.Or ce que tu veux est l'historique de l'objet. Quel est, dans la base, ce qui dit c'est un objet ? Si t'as pas ça on tombe forcément dans le pataquès dénoncé, avec son style bien à lui, par Philippe. Je passe le baton de parole au suivant. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
+1 pile quand je parle d'osm a une collegue de bureau ! Rha l'effet démo :( 2013/1/4 Cyrille Giquello cyrill...@gmail.com Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Le 4 janvier 2013 16:39, Florian LAINEZ winner...@free.fr a écrit : +1 pile quand je parle d'osm a une collegue de bureau ! Rha l'effet démo :( Et ce serveur sert les tuiles pour les français, italiens, espagnols ... Aïe aïe aïe. Ca va pas plaire à la fondation ... Les français ont déjà une mauvaise réputation ;-) C. 2013/1/4 Cyrille Giquello cyrill...@gmail.com Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Oui j'ai aussi ça (toute la frontière franco-italienne jusque vers Genève et Midi-Pyrénées entre Pau et Toulouse): http://layers.openstreetmap.fr/?zoom=8lat=44.7683lon=4.20999layers=B00 http://layers.openstreetmap.fr/?zoom=9lat=44.4213lon=5.60363layers=B00FFFT Plus grave presque toute la France: http://layers.openstreetmap.fr/?zoom=8lat=44.7683lon=4.20999layers=B00 Une bonne partie de l'Europe occidentale et de l'Afrique du Nord: http://layers.openstreetmap.fr/?zoom=6lat=26.0932lon=13.50644layers=B00 S'agit-il d'une anomalie lors du chargement des nouvelles lignes de côtes ? 2013/1/4 Cyrille Giquello cyrill...@gmail.com: Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
l'erreur est plus détaillée sur: http://a.tile.openstreetmap.org/8/128/93.png Unable to forward this request at this time. Visiblement le proxy de Pau ne se connecte plus au serveur principal 2013/1/4 Philippe Verdy verd...@wanadoo.fr: Oui j'ai aussi ça (toute la frontière franco-italienne jusque vers Genève et Midi-Pyrénées entre Pau et Toulouse): http://layers.openstreetmap.fr/?zoom=8lat=44.7683lon=4.20999layers=B00 http://layers.openstreetmap.fr/?zoom=9lat=44.4213lon=5.60363layers=B00FFFT Plus grave presque toute la France: http://layers.openstreetmap.fr/?zoom=8lat=44.7683lon=4.20999layers=B00 Une bonne partie de l'Europe occidentale et de l'Afrique du Nord: http://layers.openstreetmap.fr/?zoom=6lat=26.0932lon=13.50644layers=B00 S'agit-il d'une anomalie lors du chargement des nouvelles lignes de côtes ? 2013/1/4 Cyrille Giquello cyrill...@gmail.com: Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Le vendredi 04 janvier 2013 à 16:33 +0100, Cyrille Giquello a écrit : Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. Heuuu tu peux m'en dire plus Je viens de me connecter et ça a l'air de fonctionner ! http://tile.paulla.asso.fr/openlayers.html Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Le vendredi 04 janvier 2013 à 16:33 +0100, Cyrille Giquello a écrit : Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. Ha oui tu as raison, le rendu **Mapnik** ne fonctionne pas... je regarde pourquoi... Librement -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Le serveur Paula fonctionne lui, mais pas le proxy qui sert les requêtes effectuées sur http://[a/b/c].tile.openstreetmap.org/zoom/x/y.png Cela ressemble fort à un problème de DNS, peut-être pas sur Paula directement mais sur le serveur DNS du domane openstreetmap.org (qui doit renvoyer vers la mauvaise adresse IP, bien que chez moi cela résolve sur 193.55.222.229). Paula est sur 193.55.222.227 Le 4 janvier 2013 16:47, Christophe Merlet red...@redfoxcenter.org a écrit : Le vendredi 04 janvier 2013 à 16:33 +0100, Cyrille Giquello a écrit : Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. Heuuu tu peux m'en dire plus Je viens de me connecter et ça a l'air de fonctionner ! http://tile.paulla.asso.fr/openlayers.html Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Le vendredi 04 janvier 2013 à 16:33 +0100, Cyrille Giquello a écrit : Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. Les admins OSM sont sur le coup :) Le problème semble commun à tous les serveurs de tuiles... Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
C:\Users\Philippenslookup tile.paulla.asso.fr Serveur : ns1.numericable.net Address: 89.2.0.1 Réponse ne faisant pas autorité : Nom :cannelle.paulla.asso.fr Address: 193.55.222.227 Aliases: tile.paulla.asso.fr C:\Users\Philippenslookup a.tile.openstreetmap.org Serveur : ns1.numericable.net Address: 89.2.0.1 Réponse ne faisant pas autorité : Nom :pau.tile.openstreetmap.org Address: 193.55.222.229 Aliases: a.tile.openstreetmap.org tile.geo.openstreetmap.org fr.tile.openstreetmap.org Mauvaise adresse sur le DNS d'openstreetmap.org, visiblement. Le 4 janvier 2013 16:54, Christophe Merlet red...@redfoxcenter.org a écrit : Le vendredi 04 janvier 2013 à 16:33 +0100, Cyrille Giquello a écrit : Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. Les admins OSM sont sur le coup :) Le problème semble commun à tous les serveurs de tuiles... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Le 04/01/2013 16:24, Ista Pouss a écrit : Le 4 janvier 2013 15:38, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Rappel: name[:1970]=Place de l'Etoile Malheureusement les dates sont un des nids à problèmes de l'informatique et, à ma connaissance, il n'existe pas de solution universelle. Surtout que ta proposition suppose que ce soit une plage de dates, et non une date seule, qui indexe le nom. Car j'imagine que tu vas vouloir dire quel était le nom de cette place en 1969, un jour. Ce n'est pas impossible, mais je ne sens absolument pas OSM assez robuste pour ça. Surtout que, sauf erreur, le name n'est qu'un tag parmi d'autres, qui ne distingue absolument pas l'objet terrain.Or ce que tu veux est l'historique de l'objet. Quel est, dans la base, ce qui dit c'est un objet ? Si t'as pas ça on tombe forcément dans le pataquès dénoncé, avec son style bien à lui, par Philippe. Je passe le baton de parole au suivant. Un exemple (suivant ISO 8601 pour la notation des dates et intervalles) pour un POI : shop:[1985/1999-07]=florist name:[1985/1999-07]=Mille Fleurs shop:[1999-08/2005-02-21]=butcher name:[1999-08/2005-02-21]=L'entrecôte shop=electronics name=Fréquences On voit trois états successifs du magasin. L'état actuel est supposé être celui par défaut, ne comprenant pas de date de validité. Pour une ancienne commune, sur une relation : boundary:[/2011]=administrative name:[/2011]=Trifouilly-les-Oies ... Dans l'état actuel, les valeurs ne sont plus valides Cette formule reste compatible avec l'existant. Les outils lambda n'utiliseront pas les tags *:[*] La limite, c'est les collisions du genre : shop:[1985/1999-07]=florist amenity=pub En 1990, c'était déjà un bar ? L'autre limite, c'est, dans le premier exemple, en 1980, la boutique était electronics, la valeur par défaut ? Bon. JOSM trouvera vite un plugin et un validateur pour gérer cette couche temporelle, genre openning_hours, mais je redoute que certains éditeurs, que je ne nommerai pas, aient du mal. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Le 4 janvier 2013 16:03, Philippe Verdy verd...@wanadoo.fr a écrit : Le 4 janvier 2013 15:38, Christian Quest cqu...@openstreetmap.fr a écrit : C'est l'utilisation de tags standards qui crée la confusion. Ajouter un tag (comme historic=yes) ne résoudra le problème que pour les outils tenant compte de celui-ci, ce n'est donc pas une bonne solution à mon avis. Le principe du suffixe aux tags ne vous semble pas intéressant à creuser ? Rappel: name[:1970]=Place de l'Etoile Cela ne marche QUE pour les objets dont la géométrie n'a pas évolué. Oui, mais c'est déjà une première étape pour pouvoir indiquer des caractéristiques qui ont pu changer, sans que la géométrie de change ou assez peu pour qu'on puisse la confondre avec l'existante. Là je parlais des objets limités différemment (par exemples des fusions/scissions de cmmunes ou d'EPCI ou d'arrondissements, ou changements du découpage cantonal/électoral, voire aussi les anciens pays comme la Tchécoslavquie, ou l'Union soviétique, ou la RDA, font il est aberrant de ne plus pouvoir dresser une carte alors qu'on a souvent besoin de les montrer pour expliquer l'histoire, ou encore les variations des frontières de la France au cours des siècles, y compris les départements d'Alsace et Lorraine pendant les conflits avec l'Allemagne depuis 1870, ou encore les cartes des anciens empires français et britanniques). Pour ces objets là, on peut très bien garder une copie de la relation et modifier les tags pour qu'ils indique qu'on décrit un objet passé. boundary=xxx - boundary[dates]=xxx Pourtant l'histoire a fourni des traces persistantes dans les statuts légaux et traités internationaux (par exemple en Alsace-Moselle pour le concordat), qu'il est difficile de matérialiser sans support par une carte montrant ces historiques. Il y a aussi le cas des collectivités en transition (deux coexistent dans la même période : il n'est pas toujours poassible de choisir l'une ou l'autre comme plus actuelle, même si leurs tags sont différents) : on a donc besoin d'objets séparés marqués entièrement eux-mêmes comme historiques avec leur propre ID séparé des objets actuels. Tout à fait. Et pouvoir disposer d'un filtre permettant de masquer AUTOMATIQUEMENT certains objets historiques (tant qu'on ne les demande pas EXPLICITEMENT dans une requête) serait préférable à l'introduction de tags spéciaux comme name[:1970] : à mon avis c'est mieux de coder deux objets séparés chacun avec leur date de validité et la possibilité d'en cacher certains par défaut. Un masquage à quel niveau ? Au niveau de l'API ? au niveau du rendu ? Avec ces tags, ils sont forcément masqués au niveau du rendu car ne correspondent plus à des tags utilisés par les moteurs de rendu (sauf ceux qui voudraient en tirer parti). Pour l'API, les masquer me semble dangereux. Pour les dumps, on peut très bien les filtrer si on n'a en a pas l'usage. Le 4 janvier 2013 16:24, Ista Pouss ista...@gmail.com a écrit : Malheureusement les dates sont un des nids à problèmes de l'informatique et, à ma connaissance, il n'existe pas de solution universelle. Surtout que ta proposition suppose que ce soit une plage de dates, et non une date seule, qui indexe le nom. Car j'imagine que tu vas vouloir dire quel était le nom de cette place en 1969, un jour. name[:1970] indique que jusqu'en 1970 elle portait ce nom. Je m'inspire de la gestion des dates en généalogie où on peut avoir une date floue qui se précise petit à petit en fonction des recherches. Si on a une information partielle, on peut la noter, puis l'améliorer au fur et à mesure des sources d'infos. Ex: un plan de 1861 indique un nom pour une rue, je peux mettre name[1861]=xxx Un autre le 1820 porte le même nom, on peut en déduire avec de faible chance d'erreur ce tag... name[1820:1861]=xxx Pour exploiter ces informations, il faut bien sûr un traitement complémentaire sur les tages pour en extraire les dates de début/fin, mais au moins, l'info est disponible, et pas trop complexe à saisir, sans venir mettre le bazar dans les utilisations courantes de données. Ce n'est pas impossible, mais je ne sens absolument pas OSM assez robuste pour ça. Pas robuste pour quelques tags en plus ? Surtout que, sauf erreur, le name n'est qu'un tag parmi d'autres, qui ne distingue absolument pas l'objet terrain.Or ce que tu veux est l'historique de l'objet. Quel est, dans la base, ce qui dit c'est un objet ? Si t'as pas ça on tombe forcément dans le pataquès dénoncé, avec son style bien à lui, par Philippe. Ce n'est pas vraiment l'historique de l'objet que je cherche à avoir (même si ça peut être un moyen de le faire), mais un moyen minimal de noter des informations passées liées à un objet ou de préserver une information intéressante qui sinon risque de disparaitre suite à un changement récent par l'unicité des tags. En 2009, une présentation au SOTM parlait de cela justement:
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
server a.ns.bytemark.co.uk set querytype=ALL pau.tile.openstreetmap.org Serveur : a.ns.bytemark.co.uk Addresses: 2001:41c8:2::3 80.68.80.26 80.68.80.26 pau.tile.openstreetmap.org internet address = 193.55.222.229 openstreetmap.org nameserver = a.ns.bytemark.co.uk openstreetmap.org nameserver = b.ns.bytemark.co.uk openstreetmap.org nameserver = c.ns.bytemark.co.uk a.ns.bytemark.co.uk internet address = 80.68.80.26 a.ns.bytemark.co.uk IPv6 address = 2001:41c8:2::3 a.ns.bytemark.co.uk internet address = 80.68.80.26 b.ns.bytemark.co.uk internet address = 85.17.170.78 c.ns.bytemark.co.uk internet address = 80.68.80.27 c.ns.bytemark.co.uk internet address = 80.68.80.27 (Réponse faisant autorité chez l'hébergeur bytemark.co.uk qui ne renseigne que l'adresse IP .229 et pas .227 pour le serveur de Pau). Est-ce que Paulla a changé son adresse IP récemment ? Ou est-ce une erreur de saisie lors d'une mise à jour du domaine openstreetmap.org chez son hébergeur? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Le vendredi 04 janvier 2013 à 16:56 +0100, Philippe Verdy a écrit : C:\Users\Philippenslookup tile.paulla.asso.fr Serveur : ns1.numericable.net Address: 89.2.0.1 Réponse ne faisant pas autorité : Nom :cannelle.paulla.asso.fr Address: 193.55.222.227 Aliases: tile.paulla.asso.fr C:\Users\Philippenslookup a.tile.openstreetmap.org Serveur : ns1.numericable.net Address: 89.2.0.1 Réponse ne faisant pas autorité : Nom :pau.tile.openstreetmap.org Address: 193.55.222.229 Aliases: a.tile.openstreetmap.org tile.geo.openstreetmap.org fr.tile.openstreetmap.org Mauvaise adresse sur le DNS d'openstreetmap.org, visiblement. Non non. les DNS sont bons. tile.paulla.asso.fr est le serveur de tuiles de PauLLA avec sa propre base de données mapnik et ses propres styles. pau.tile.openstreetmap.org est le serveur cache de tuiles officiel d'OSM. 2 machines bien différentes. Le problème est ailleurs, a priori sur le serveur principal d'OSM et les admins OSM sont sur le coup. En attendant la résolution correct du problème, le serveur parent a été basculé sur un backup de tuiles statiques. Ce n'est pas parfait, mais ça devrait aller mieux. Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Dernière note : le geoDNS d'OpenStreetmap fait une résolution assez bizarre: a.tile.openstreetmap.orgcanonical name = tile.geo.openstreetmap.org tile.geo.openstreetmap.org canonical name = fr.tile.openstreetmap.org fr.tile.openstreetmap.org canonical name = pau.tile.openstreetmap.org pau.tile.openstreetmap.org internet address = 193.55.222.229 Autrement dit 3 redirections CNAME successives. Pourquoi fr.tile.openstreetmap.org renvoie sur pau.tile.openstreetmap.org pour finalement retourner lui-même l'adresse au lieu de directement le bon domaine en canonical name (pau.tile.openstreetmap.org me semble redondant, c'est le même CNAME aussi pour es.tile.openstreetmap.org donc l'Espagne est touchée aussi) Le 4 janvier 2013 17:06, Philippe Verdy verd...@wanadoo.fr a écrit : server a.ns.bytemark.co.uk set querytype=ALL pau.tile.openstreetmap.org Serveur : a.ns.bytemark.co.uk Addresses: 2001:41c8:2::3 80.68.80.26 80.68.80.26 pau.tile.openstreetmap.org internet address = 193.55.222.229 openstreetmap.org nameserver = a.ns.bytemark.co.uk openstreetmap.org nameserver = b.ns.bytemark.co.uk openstreetmap.org nameserver = c.ns.bytemark.co.uk a.ns.bytemark.co.uk internet address = 80.68.80.26 a.ns.bytemark.co.uk IPv6 address = 2001:41c8:2::3 a.ns.bytemark.co.uk internet address = 80.68.80.26 b.ns.bytemark.co.uk internet address = 85.17.170.78 c.ns.bytemark.co.uk internet address = 80.68.80.27 c.ns.bytemark.co.uk internet address = 80.68.80.27 (Réponse faisant autorité chez l'hébergeur bytemark.co.uk qui ne renseigne que l'adresse IP .229 et pas .227 pour le serveur de Pau). Est-ce que Paulla a changé son adresse IP récemment ? Ou est-ce une erreur de saisie lors d'une mise à jour du domaine openstreetmap.org chez son hébergeur? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Le 4 janvier 2013 17:02, Vincent Pottier vpott...@gmail.com a écrit : Un exemple (suivant ISO 8601 pour la notation des dates et intervalles) pour un POI : shop:[1985/1999-07]=florist name:[1985/1999-07]=Mille Fleurs shop:[1999-08/2005-02-21]=butcher name:[1999-08/2005-02-21]=L'entrecôte shop=electronics name=Fréquences On voit trois états successifs du magasin. L'état actuel est supposé être celui par défaut, ne comprenant pas de date de validité. Pour une ancienne commune, sur une relation : boundary:[/2011]=administrative name:[/2011]=Trifouilly-les-Oies ... Dans l'état actuel, les valeurs ne sont plus valides Je ne connaissais pas la notation des intervalle ISO, ça me semble plus propre comme ça. tag:[intervalleISO] Cette formule reste compatible avec l'existant. Les outils lambda n'utiliseront pas les tags *:[*] La limite, c'est les collisions du genre : shop:[1985/1999-07]=florist amenity=pub En 1990, c'était déjà un bar ? C'est pas parfait, mais c'est mieux que rien ;) L'autre limite, c'est, dans le premier exemple, en 1980, la boutique était electronics, la valeur par défaut ? Dans ce cas j'aurai ajouté un shop:[/1985]=electronics On devrait considérer que par défaut tag=xxx est équivalent à tag[plus grande date/]=xxx Bon. JOSM trouvera vite un plugin et un validateur pour gérer cette couche temporelle, genre openning_hours, mais je redoute que certains éditeurs, que je ne nommerai pas, aient du mal. Tant que ça ne leur pose pas de problème, ils les ignorent un point c'est tout. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] (sans objet)
Il serait effectivement intéressant de voir davantage de personnes hors France s'exprimer. Surtout qu'il y a des discussions très intéressantes sur cette liste, et de nombreuses initiatives à découvrir. Mais bon, c'est fou pour certains sujets comment il peut y avoir un grand nombre d'interventions. Trop c'est trop! Pour des sujets relativement banals, chacun y met son grain de sel pas toujours bien épicé. Si certains pouvaient prendre de bonnes résolutions de nouvelle année et limiter les réponses ad infinitum, ce tant dans leur longueur que leur fréquence et leur redite. Un petit truc, ré-écrivez votre courriel ou tournez autour de la langue sept fois avant de l'envoyer. Vous verrez que ça défoule et vous donne le temps de voir l'inutilité de partager ce propos. Entre-temps, tant de sujets nouveaux à lire et commenter. Fin de la dictée! Pierre De : Pieren pier...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Vendredi 4 janvier 2013 8h33 Objet : Re: [OSM-talk-fr] (sans objet) 2013/1/4 ismaila ndiaye hote...@gmail.com Bienvenue Odette, ismaila sénégalais étudiant à Saint-Louis. Et en passant, un gros bienvenue sur cette liste de diffusion à tous les francophones du monde entier. Et excusez-nous par avance si les discussions sont parfois un peu trop... franco-françaises ! Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
En attendant la résolution correct du problème, le serveur parent a été basculé sur un backup de tuiles statiques. Ce n'est pas parfait, mais ça devrait aller mieux. Oui on voit que /dirty et /status ne sont pas supportés sur ce serveur statique (donc pas de rendu, juste les tuiles déjà stockées en cache, et pas de rendu aux zooms fins) C'est gênant pour sélectionner une zone fine à charger dans JOSM puisque ces tuiles ne sont pas persistantes ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Panne de courant. On essaie de trouver quelqu'un pour aller redémarrer les serveurs On 4 Jan 2013 15:54, Christophe Merlet red...@redfoxcenter.org wrote: Le vendredi 04 janvier 2013 à 16:33 +0100, Cyrille Giquello a écrit : Hello, De chez moi le rendu Mapnik ne fonctionne plus, plus de tuiles ... On dirait que le serveur est out : 504 Gateway Time-out. Les admins OSM sont sur le coup :) Le problème semble commun à tous les serveurs de tuiles... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Ce formalisme serait-il requêtable en xquery ou même en SQL? Le 4 janvier 2013 17:11, Christian Quest cqu...@openstreetmap.fr a écrit : Le 4 janvier 2013 17:02, Vincent Pottier vpott...@gmail.com a écrit : Un exemple (suivant ISO 8601 pour la notation des dates et intervalles) pour un POI : shop:[1985/1999-07]=florist name:[1985/1999-07]=Mille Fleurs shop:[1999-08/2005-02-21]=butcher name:[1999-08/2005-02-21]=L'entrecôte shop=electronics name=Fréquences On voit trois états successifs du magasin. L'état actuel est supposé être celui par défaut, ne comprenant pas de date de validité. Pour une ancienne commune, sur une relation : boundary:[/2011]=administrative name:[/2011]=Trifouilly-les-Oies ... Dans l'état actuel, les valeurs ne sont plus valides Je ne connaissais pas la notation des intervalle ISO, ça me semble plus propre comme ça. tag:[intervalleISO] Cette formule reste compatible avec l'existant. Les outils lambda n'utiliseront pas les tags *:[*] La limite, c'est les collisions du genre : shop:[1985/1999-07]=florist amenity=pub En 1990, c'était déjà un bar ? C'est pas parfait, mais c'est mieux que rien ;) L'autre limite, c'est, dans le premier exemple, en 1980, la boutique était electronics, la valeur par défaut ? Dans ce cas j'aurai ajouté un shop:[/1985]=electronics On devrait considérer que par défaut tag=xxx est équivalent à tag[plus grande date/]=xxx Bon. JOSM trouvera vite un plugin et un validateur pour gérer cette couche temporelle, genre openning_hours, mais je redoute que certains éditeurs, que je ne nommerai pas, aient du mal. Tant que ça ne leur pose pas de problème, ils les ignorent un point c'est tout. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
J'ajoute mes commentaires a ceux de Christophe. Les serveurs DNS sont bons. On a eus une coupure de courant a l'UCL ce qui a fait plante le serveur (Yevaud) mettant le contrôleur RAID en rade. Il faut que quelqu'un se déplace pour débrancher et rebrancher tout cela pour que cela fonctionne. Grant ne peut se déplacer et Matt (Amos) devrait bientôt y aller une fois une réunion finie. Dans mon cas, je pars bientôt en réunion ce qui fait que ce n'est pas possible pour moi. Il ne faut pas chercher midi a 14h Philippe. 2013/1/4 Christophe Merlet red...@redfoxcenter.org Le vendredi 04 janvier 2013 à 16:56 +0100, Philippe Verdy a écrit : C:\Users\Philippenslookup tile.paulla.asso.fr Serveur : ns1.numericable.net Address: 89.2.0.1 Réponse ne faisant pas autorité : Nom :cannelle.paulla.asso.fr Address: 193.55.222.227 Aliases: tile.paulla.asso.fr C:\Users\Philippenslookup a.tile.openstreetmap.org Serveur : ns1.numericable.net Address: 89.2.0.1 Réponse ne faisant pas autorité : Nom :pau.tile.openstreetmap.org Address: 193.55.222.229 Aliases: a.tile.openstreetmap.org tile.geo.openstreetmap.org fr.tile.openstreetmap.org Mauvaise adresse sur le DNS d'openstreetmap.org, visiblement. Non non. les DNS sont bons. tile.paulla.asso.fr est le serveur de tuiles de PauLLA avec sa propre base de données mapnik et ses propres styles. pau.tile.openstreetmap.org est le serveur cache de tuiles officiel d'OSM. 2 machines bien différentes. Le problème est ailleurs, a priori sur le serveur principal d'OSM et les admins OSM sont sur le coup. En attendant la résolution correct du problème, le serveur parent a été basculé sur un backup de tuiles statiques. Ce n'est pas parfait, mais ça devrait aller mieux. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Le 4 janvier 2013 17:20, Emilie Laffray emilie.laff...@gmail.com a écrit : Il ne faut pas chercher midi a 14h Philippe. Ce n'est pas moi qui ai indiqué l'adresse de Paulla ici. J'ai juste constaté que c'était des adresses IP différentes. Ce n'est pas chercher midi à 14h. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Moui ce que tu exposes comme point est discute depuis des annees sans reponses convenables. Comme il a ete signale plus tot dans le fil de discussion, il faudrait passer a une autre version de l'API au final car gerer 4 dimensions avec le systeme actuel n'est tout simplement faisable. De plus, je vois de gros risques d'augmentation de la complexite dans la coherence des donnees si on ne fait pas gaffe. Je suis pour un support des donnees historiques mais je suis convaincue que ce n'est pas juste en passant un nouveau parametre comme tu le proposes que l'on resoudra le probleme. Il y a deja eus des publications de chercheurs utilisant une architecture OSM pour une juxtaposition mais tous concluent que la structure n'est pas encore adaptee a cela. Donc oui pour les donnees historiques, non au bidouillage. Il y a trop de risques avec des problemes de conflation temporelles (nodes, ways comme pour les rues, les rivieres) pour que l'on resolve cela aussi facilement. Emilie Laffray 2013/1/4 Christian Quest cqu...@openstreetmap.fr C'est l'utilisation de tags standards qui crée la confusion. Ajouter un tag (comme historic=yes) ne résoudra le problème que pour les outils tenant compte de celui-ci, ce n'est donc pas une bonne solution à mon avis. Le principe du suffixe aux tags ne vous semble pas intéressant à creuser ? Rappel: name[:1970]=Place de l'Etoile - pas de risque de confusion - possibilité d'en avoir plusieurs car des changements il peut y en avoir eu plus d'un ! -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] (sans objet)
Bienvenue sur la liste. Emilie Laffray 2013/1/4 aida odette odette...@yahoo.fr bonjour mon est Odette je suis sénégalaise je à Dakar je viens de connaitre openstreetmap et pour mieux comment sa se présente je me suis inscrite sur votre liste. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Le 4 janvier 2013 17:02, Christian Quest cqu...@openstreetmap.fr a écrit : Et pouvoir disposer d'un filtre permettant de masquer AUTOMATIQUEMENT certains objets historiques (tant qu'on ne les demande pas EXPLICITEMENT dans une requête) serait préférable à l'introduction de tags spéciaux comme name[:1970] : à mon avis c'est mieux de coder deux objets séparés chacun avec leur date de validité et la possibilité d'en cacher certains par défaut. Un masquage à quel niveau ? Au niveau de l'API ? Oui au niveau du rendu ? Non. Avec ces tags, ils sont forcément masqués au niveau du rendu car ne correspondent plus à des tags utilisés par les moteurs de rendu (sauf ceux qui voudraient en tirer parti). Pour l'API, les masquer me semble dangereux. Non. Ce qu'on veut c'est juste un filtre par défaut qui ne retourne pas ces objets historiques, partout (rendus, éditeurs), SAUF si on les demande explicitement. Ainsi tout continue à tourner comme maintenant, et il faudra faire des rendus avec des requêtes API spécifiques pour afficher les historiques (à ces moteurs alors de faire le tri entre les dates pour prendre en compte une date de validité). Par défaut l'API ne retournerait que les objets qui sont dans la période de validité actuelle. Il suffirait de faire une requête en mentionnant une autre date qu'aujourd'hui, ou un intervalle de dates pour avoir différentes versions, ou une requête mentionnant toutes dates. Bref un paramètre supplémentaire de requête optionnel du genre dates=-mm-dd/-mm-dd (recherche dans un intervalle) ou dates=-mm-dd (recherche à une date donnée) ou dates=* (toutes les dates), la valeur par défaut étant dates=today Bref on ne supprimerait plus rien dans la base, on changerait juste un tag de dates de validité pour un objet, qui ensuite ne serait plus accessible en référence à une date donnée. L'objet persiste dans la base et reste accessible malgré tout si on le demande explicitement avec son ID, mais n'est plus retourné par un téléchargement par zone. Si l'objet est membre d'une relation, ou est un noeud membre d'un chemin, le validateur peut encore vérifier la cohérence référencielle en utilisant les dates de début et fin validité de chaque objet. Mais pour la majorité des utilisations, on ne s'occupera plus de ce chemin, et un éditeur en mode simple pourra aussi avoir un filtre n'affichant que les membres d'une date donnée (par défaut la date actuelle), avec unsélecteur de date pour le voir à une autre date. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Figurer le siège d'un EPCI (était : Numéro de rue ?)
2013/1/4 Vincent de Chateau-Thierry v...@laposte.net: Au passage, impossible de remettre la main dans le wiki sur une page décrivant l'intention du rôle admin_centre. J'ai l'impression que ta page de proposition a été effacée mais sans transfert du contenu ailleurs contrairement au commentaire ici : http://wiki.openstreetmap.org/wiki/Relations/Proposed/add_admin_centre_in_Relation:bounda ry Si on cherche admin_centre dans le wiki, on est redirigé vers cette page: http://wiki.openstreetmap.org/wiki/Relation:boundary où l'admin_centre est brièvement décrit: Node representing the administrative centre, usually a town, city or village (depending of the boundary level, see place=*) C'est suffisament précis pour être compris et vague pour être utilisé à toutes les sauces administratives ;) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Tout ce que vous suggérez (et plus encore) est présenté dans ce slideshare montré au SOTM de ... 2009: http://www.slideshare.net/frankieroberto/mapp-history-on-open-street-map Bonne lecture, Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Libération couche occupation du sol et Ortho-Photos aériennes de la réserve naturelle des Hauts plateaux du Vercors
Bonjour,
Les orthophotos à 1 m et 75 cm de résolution de la Réserve naturelle des
Hauts-Plateaux du Vercors (1999), récemment libérées par le Parc Naturel
Régional du Vercors, sont maintenant en ligne sur le serveur d'imagerie
de l'association OSM France, qui se trouve être hébergé à l'Université
Pierre Mendès France de Grenoble. C'est l'occasion de lui adresser un
clin d'œil, et des remerciements.
En TMS :
URL pour JOSM (à ajouter dans Préférences/WMS-TMS) :
tms[19]:http://wms.openstreetmap.fr/tms/1.0.0/PNRVercors-RHP-1999/{zoom}/{x}/{y}
Pour Potlatch2 (à ajouter en arrière plan) :
http://wms.openstreetmap.fr/tms/1.0.0/PNRVercors-RHP-1999/$z/$x/$y
et en WMS, à partir de : http://wms.openstreetmap.fr/wms?
La Licence ouverte est disponible sur :
http://www.parc-du-vercors.fr/fr_FR/comprendre-et-partager-1110/telechargements-3115.html
(Notez que Bing en haute résolution est bien sûr aussi disponible).
Cordialement,
Jean-Guilhem
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Bref c'est exactement ce que je proposais plus haut qui résoud tous les problèmes, sauf que le slide suggère l'addition de champs start_date/end_date pour chaque attribut, ce que je trouve plutôt redondant, on peut très bien se débrouiller avec des objets distincts, avec juste cette parire d'attributs pour une objet. Leur idée de dater les attributs est que pour eux il s'agit du même objet (mais l'ennui ce sont les références depuis un autre objet : il faudrait alors dater chaque noeud inclus dans un chemin, et chaque membre d'une relation. Il me semble plus propre de ne mettre qu'une paire par objet, pas pour chacun de ses membres, et de considérer que ce sont des objets différents, comme si c'était des couches d'une autre dimension : - imaginons qu'une communauté de communes référence deux communes mais que ces communes fusionnent - on crée une nouvelle relation pour la nouvelle commune (même si elle conserve le même nom et même numéro INSEE, mais probablement pas le même numéro ref:SIREN=21depCOMx qui a des incidences comptables car les comptes de chaque entité coexistent pendant un certain temps le temps que les transferts de responsabilité et engagements financiers ou contractuels se terminent). - on crée une nouvelle relation pour la nouvelle communauté de communes puisque ses membres ont changé et sa géométrie a pu changer - les anciennes relations de la commune et de la communauté de communes persistent mais on leur met une date de fin de validité.L'ancienne communauté de commune continue de référencer l'ancienne relation : la contrainte est que les membres de la relation de communauté de communes doivent avoir des dates de validité totalement incluses dans la période de validité de la communauté de communes. Le problème est : que faire quand il y a des incertitudes de dates, en terme de validité référencielle ? Il faut une règle permettant une tolérance. Par exemple quand on a start_date=c1890 (circa 1890) dans une objet référent, il s'agit d'une tolérance de l'ordre de la décennie, comme si la date de début validité du référent commençait en 1895, 5 ans plus tart (sans aller au delà de la date indiquée en end_date) ; dans l'objet référé la date de début de validité c1890 est étendue 5 ans plus tôt à partir de 1885, de sorte que la validité de l'objet référent est entièrement incluse dans l'objet référencé. Toutefois un validateur en mode strict fera un test de date sans tolérance et affichera un warning pour vérifier si les dates sont compatibles. Même chose si une date mentionne une décennies sous la forme start_date=1890s. Si la date de début mentionne juste une année, on peut réduit la tolérance à moins d'un an; si la date mentionne le mois, on réduit la tolérance à moins d'un mois. Si la date mentionne le jour la tolérance est de moins de quelques heures ; je ne suis pas sûr qu'il faille prendre en compte les heures dans les champs date, mais le format ISO8601 standard (-mm-ddThh:mi:ssZ) le permet. Si l'incertitude de la date de début (ou de fin) est différente, on pourrait encore avoir start_date=1890-02-28+7d pour préciser un intervalle d'incertitude de plus ou moins 7 jours autour de cette date (donc ici dans 14 jours ou 15 dates). start_date=1890+2y indiquerait une tolérance de plus ou moins 2 ans avant ou après 1890. L'autre solution étant de traduire directement cet intervalle de dates en deux attributs donnant des dates précises si cela facilite les requêtes SQL : start_date=1890-02-21..1892-03-07 et start_date=1888..1892 pour les deux cas précédents. Les incertitudes de dates peuvent exister pour la date de début comme pour la date de fin de validité (les 4 dates sont alors en ordre croissant ; la paire à utiliser pour les tests de référence sont de prendre le plus plus grand intervalle des dates 1 et 4 pour l'objet référencé, et le plus petit intervalle des dates 2 et 3 pour l'objet référent). Certes cela duplique les objets et les attributs, mais il est plus simple de gérer l'intégrité référentielle au niveau de chaque objet ayant un ID unique qu'avec un seul objet avec des attributs dont les valeurs sont datés et deviennent des listes de valeurs. Mais des solutions peuvent être développées pour les éditeurs qui veulent vouloir pouvoir saisir un même objet avec des attributs (et membres de relation) datés individuellement. Il est même possible de lier ces objets à un objet maître liant les ID d'objets entre eux dans une liste odonnée par date avec une relation spéciale de type history comme une relation normale, sauf que les relations elles-mêmes ou autres objets ne sont pas modifiés, il n'y a que la nouvelle relations spéciale qui au lieu de contenir des listes d'objets quelconque contient une liste d'ID d'objets avec chacun leurs intervalles de date de validité au lieu du rôle (cette relation spéciale appliquant des contraintes : les intervalles ne doivent avoir aucune intersection hors des intervalles de tolérance). Bref aucune modification du schéma des objets
Re: [OSM-talk-fr] Figurer le siège d'un EPCI (était : Numéro de rue ?)
Pas vraiment. Le fait que ce soit un nœud uniquement est stupide et conduit à une définition arbitraire du noeud. La capitale de la France n'est pas un noeud placé à l'Hôtel de ville de Paris (où ça d'ailleurs ?). C'est de là ensuite que viennent les différences d'interprétation entre le placement sur une place centrale, ou quelquepart dans la commune à un carrefoiur ou au milieu de la place de la Mairie ou dans un parking, ou devant la porte d'entrée du bâtiment, ou au point d'entrée depuis la rue, ou qulequpart à la préfecture. Ces noeud admin_center ici ne sert finalement que pour placer un label pouvant se substituer tout seul à la représentation de toute la surface de la commune mais il ne permet même pas de trouver la mairie ou les bâtiments administratifs municipaux et ne fait aucune distinction sur ce que cela doit être. Si on tague une commune pourtant son admi_center devrait être la mairie et rien d'autre. Mais pour un arrondissement, un département ou une région pourquoi est-ce la mairie ? Ce nœud devrait aller sur la préfecture ou sous-préfecture (dans la relation de niveau 7 pour l'arrondissement). Mais où entre la préfecture ou le conseil général ou le Conseil de Paris (pour le niveau 6) ? Où entre la préfecture de région et le conseil régional (pour le niveau 4) ? Et quoi alors pour le niveau 2 (pays) alors que c'est toute la ville qui est capitale pour y inclure les institutions nationales (la présidence à l'Elysée, les deux chambres du parlement, le conseil constitutionnel, la Cour des Comptes, le palais Bourbon pour le cabinet du Premier ministre, seuls les autres différents ministères et secrétariat d'Etat pouvant avoir leur siège situé hors de Paris : ces institutions ne sont PAS dans la compétence de la Ville de Paris qui ne gère rien au niveau national, donc n'a rien à faire à l'Hôtel de Ville de Paris) ? C'est pour ça que je pense que le membre de rôle admin_centre ne devrait pas être restreint à un nœud et devrait pouvoir référencer une autres subdivision administrative. Si on y met un nœud, il n'a de sens que comme label mais ne doit pas être lié à quelquechose de physique, donc pas à la Mairie (il me semble que pour Paris, ce noeud devrait être à la borne kilométrique zéro devant Notre-Dame). Mais ce nœud utiliser pour se substituer à la surface représentée par las relation (quand on ne peut pas la représenter elle-même) n'a rien à voir avec un admin_centre, ce n'est qu'un label. admin_centre devrait en revanche être plus précis et couvrir ce qu'il faut et sera souvent plus grand qu'un seul nœud. Mais comme on ne va pas tout changer, laissons admin_centre en tant que noeud non attaché à un objet (en tout cas pas à la mairie) mais il nous restera alors le besoin de référencer les rôles pertinents pour les batiments adminsitratifs de la mairie, ou pour toute la ville d'une capitale ou d'un chef-lieu. Et il nous faudra plusieurs membres pour la préfecture ou sous-préfecture d'une part (rôle executive_center que je propose), et d'autre part (le rôle capital) la capitale, le conseil général, le conseil régional ou la mairie selon le niveau (et ces deux membres ne sont pas des nœuds et peuvent être une autre subdivision administrative ou politique). Le 4 janvier 2013 17:43, Pieren pier...@gmail.com a écrit : 2013/1/4 Vincent de Chateau-Thierry v...@laposte.net: Au passage, impossible de remettre la main dans le wiki sur une page décrivant l'intention du rôle admin_centre. J'ai l'impression que ta page de proposition a été effacée mais sans transfert du contenu ailleurs contrairement au commentaire ici : http://wiki.openstreetmap.org/wiki/Relations/Proposed/add_admin_centre_in_Relation:bounda ry Si on cherche admin_centre dans le wiki, on est redirigé vers cette page: http://wiki.openstreetmap.org/wiki/Relation:boundary où l'admin_centre est brièvement décrit: Node representing the administrative centre, usually a town, city or village (depending of the boundary level, see place=*) C'est suffisament précis pour être compris et vague pour être utilisé à toutes les sauces administratives ;) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSMTransport France
J'ai contacté les responsables sur Montpellier il y a quelques semaines. La mise à jour est manuelle et faite quand ils y pensent ou sur simple demande via un émail de préférence : http://www.3liz.com/contact.html Le 4 janvier 2013 16:06, Cyrille Giquello cyrill...@gmail.com a écrit : Bonjour, OSMTransport est un démonstrateur, mais tout de même bien pratique ;-) Du coup, les données ne semblent pas très fraiches, est-ce intentionnel ou juste une panne ? Si le rafraichissement est prévu, quelle est sa fréquence ? Merci Cyrille. Le 17 octobre 2012 17:58, rldhont rldh...@gmail.com a écrit : Le 17/10/2012 14:05, Guilhem Bonnefille a écrit : Le 16 octobre 2012 17:42, Otourly Wiki otou...@yahoo.fr a écrit : Je sais pas où remonter les erreurs d'OSM transport mais le funiculaire de Lyon qui va à Saint-Just s'arrête à l'arrêt Saint-Just. La base et le rendu OSM est juste... Interrogation similaire : j'ai remarqué une incomplétude. J'ai voulu corriger dans OSM mais... je trouve moins d'information dans OSM que dans OSM transport. A quoi est-ce dû ? Vous utilisez quelles données ? Les données n'étaient peut-être pas très fraîche... PS : ce bug est en région Toulousaine J'ai mis à jour Toulouse René-Luc ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Déjà le serveur statique a ses propres problèmes : http://www.openstreetmap.org/?lat=46.4502lon=4.125zoom=14layers=M Plein de tuiles manquantes (grises) qui ne se chargent pas (visiblement les tuiles se purgent toutes seules et le serveur statique semble attendre que le serveur de rendu les rafraichissent). Ou alors ce serveur statique ne tient pas la charge (a-t-il un frontal Squid ?). Le 4 janvier 2013 17:24, Philippe Verdy verd...@wanadoo.fr a écrit : Le 4 janvier 2013 17:20, Emilie Laffray emilie.laff...@gmail.com a écrit : Il ne faut pas chercher midi a 14h Philippe. Ce n'est pas moi qui ai indiqué l'adresse de Paulla ici. J'ai juste constaté que c'était des adresses IP différentes. Ce n'est pas chercher midi à 14h. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu Mapnik chez PAULA cassé ?
Maintentant si je vide mon cache navigateur, je n'ai plus aucune tuile du tout au delà du niveau 12. Impossible de zoomer sur une commune, on a des tuiles couvrant la totalité d'une commune et un peu plus. Pourtant le serveur statique (en .229) répond en 50-55 ms en moyenne depuis mon accès Numericable. J'ai m'impression qu'il bloque un nombre considérable de requêtes, et pourtant le ne retourne aucun timeout : cela doit faire un sacré paquet de sessions HTTP en cours, et le serveur doit commencer à manquer de ports TCP vu que son timeout semble démesurément long. S'il y a un Squid frontal, peut-être faut-il réduire sa durée de timeout pour qu'il retourne une erreur 5xx et libère ses ports TCP ? ou le Squid n'a pas été dimensionné pour servir toute la France, l'Espagne et l'Italie par défaut (et combien d'autres pays?). Jusqu'à présent cela devait suffire tant que c'était occasionnel, mais là il faut visiblement le secours d'un autre cache pour les niveaux de zoom 13 et suivants. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Même après avoir lu les slides, m'est avis qu'il vaut mieux gérer ça au niveau de la primitive plutôt que ses tags... Le tags sont des données particulières de la primitive, gérer un historique à ce niveau c'est se condamner à devoir le refaire pour toute autre donnée rattachée à l'objet. Qu'on appelle ça une version ou autre chose, c'est nettement plus navigable et manipulable que d'avoir à parser des chaines de texte pour faire une sélection. La version a le mérite de relier logiquement plusieurs historiques du même objet sans avoir à créer une liaison history justement. Dans ce cas on aurait un entier supplémentaire au lieu d'une table avec plusieurs entiers nécessaires. Ce qui m'interpelle aussi, c'est que la problématique du nombre gigantesque d'enregistrements que cela va entrainer ressorte alors que moult versions obsolètes (tant sur le terrain que pour d'éventuels reverts) sont conservées par ailleurs. D'expérience je créé des vues restreintes sur les enregistrements actuels (plus peut-être à d'autres points de temps fortement fréquentés) pour obtenir non seulement une vision actuelle et un accès direct aux historiques. Concernant les liaisons entre primitives, une référence aux objets logiques (dont le numéro ne change jamais au cours du temps) consolidées par les dates de part d'autre pour connaitre la bonne version à utiliser fonctionnerait. Ceci à condition de restreindre la conservation d'un objet à sa stricte existence... on revient à la question philosophique des slides. Bon week end à tous. Le 4 janvier 2013 19:41, Philippe Verdy verd...@wanadoo.fr a écrit : Bref c'est exactement ce que je proposais plus haut qui résoud tous les problèmes, sauf que le slide suggère l'addition de champs start_date/end_date pour chaque attribut, ce que je trouve plutôt redondant, on peut très bien se débrouiller avec des objets distincts, avec juste cette parire d'attributs pour une objet. Leur idée de dater les attributs est que pour eux il s'agit du même objet (mais l'ennui ce sont les références depuis un autre objet : il faudrait alors dater chaque noeud inclus dans un chemin, et chaque membre d'une relation. Il me semble plus propre de ne mettre qu'une paire par objet, pas pour chacun de ses membres, et de considérer que ce sont des objets différents, comme si c'était des couches d'une autre dimension : - imaginons qu'une communauté de communes référence deux communes mais que ces communes fusionnent - on crée une nouvelle relation pour la nouvelle commune (même si elle conserve le même nom et même numéro INSEE, mais probablement pas le même numéro ref:SIREN=21depCOMx qui a des incidences comptables car les comptes de chaque entité coexistent pendant un certain temps le temps que les transferts de responsabilité et engagements financiers ou contractuels se terminent). - on crée une nouvelle relation pour la nouvelle communauté de communes puisque ses membres ont changé et sa géométrie a pu changer - les anciennes relations de la commune et de la communauté de communes persistent mais on leur met une date de fin de validité.L'ancienne communauté de commune continue de référencer l'ancienne relation : la contrainte est que les membres de la relation de communauté de communes doivent avoir des dates de validité totalement incluses dans la période de validité de la communauté de communes. Le problème est : que faire quand il y a des incertitudes de dates, en terme de validité référencielle ? Il faut une règle permettant une tolérance. Par exemple quand on a start_date=c1890 (circa 1890) dans une objet référent, il s'agit d'une tolérance de l'ordre de la décennie, comme si la date de début validité du référent commençait en 1895, 5 ans plus tart (sans aller au delà de la date indiquée en end_date) ; dans l'objet référé la date de début de validité c1890 est étendue 5 ans plus tôt à partir de 1885, de sorte que la validité de l'objet référent est entièrement incluse dans l'objet référencé. Toutefois un validateur en mode strict fera un test de date sans tolérance et affichera un warning pour vérifier si les dates sont compatibles. Même chose si une date mentionne une décennies sous la forme start_date=1890s. Si la date de début mentionne juste une année, on peut réduit la tolérance à moins d'un an; si la date mentionne le mois, on réduit la tolérance à moins d'un mois. Si la date mentionne le jour la tolérance est de moins de quelques heures ; je ne suis pas sûr qu'il faille prendre en compte les heures dans les champs date, mais le format ISO8601 standard (-mm-ddThh:mi:ssZ) le permet. Si l'incertitude de la date de début (ou de fin) est différente, on pourrait encore avoir start_date=1890-02-28+7d pour préciser un intervalle d'incertitude de plus ou moins 7 jours autour de cette date (donc ici dans 14 jours ou 15 dates). start_date=1890+2y indiquerait une tolérance de plus ou moins 2 ans avant ou après 1890. L'autre solution étant de
Re: [OSM-talk-fr] Données historique et historiques des données...
En vrac : Pour la notation du temps l'ISO 8601 est la moins mauvaise solution informatique, mais c'est une bombe à retardement culturelle. Comme elle est basée sur un calendrier catholique, je vous fais pas de dessin. Que l'on dise Ce n'est pas vraiment l'historique de l'objet que je cherche à avoir, mais un moyen minimal de noter des informations passées liées à un objet... ne fait que reculer pour mieux sauter : tant que t'as pas l'objet, tu mets des dates sur du vent. Impossible de justifier l'info. Avec l'historique, le terrain a disparu. L'historique impose la justification des sources, et je ne vois rien dans tes tags qui marque la justification des sources, et je ne vois rien qui marque l'objet dont les sources parlent. Après... il faut bien avancer, et il est rare qu'on avance en gardant l'équilibre. Let's go[2013-01-01T20:47+01:00]. Le 4 janvier 2013 19:41, Tout le monde a écrit : Bref c'est exactement ce que je proposais plus haut qui résoud tous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
A mon avis la création d'une version historique ne va pas entrainer une profusion de données. Le plus gros des modifs de versions est dans la branche principale (celle de la version actuelle, et cela restera celle qui sera le plus contribuée. A un instant donnée on ne crée un objet historique que pour conserver une de ces versions à peu près stable. D'autant plus qu'on peut faire en sorte que l'éditeur par défaut ne charge pas ces objets historiques sauf si on en fait la demande explicitement. Je suis d'accord avec toi que mettre cela dans des tags standards n'est pas la bonne solution et qu'il vaut mieux une primitive séparée pour créer une méta-relation listant les objets liés à un même intervalle historique daté. Un même id d'objet ne doit servir qu'à un seul intervalle de validité de date, cet objet pouvant être chargé ou pas (mais pas par défaut par l'API quant on ne précise pas une date de validité ou qu'on ne précise pas un intervalle de date à rechercher ou pas de requête pour charger toutes les dates. Ce sera d'autant plus important que pour les versions historiques, se posera la question des sources différentes, et de droits intellectuels distincts, des problèmes de licences distinctes. Imaginons ensuite qu'on veuille créer une nouvelle version historique d'un objet actuel pour en garder une archive datée, on devrait avoir un bouton permettant d'ajouter cette version en mentionnant seulement la date de fin de l'objet actuel et de début du nouvel objet. Les deux objets sont alors soumis au serveur. L'ancien objet change de statut (il est modifié) ce qui oblige les autres éditeurs à en tenir compte comme une modif puisque l'ancien objet sera versionné comme une modif standard. Mais il deviendra invisible ensuite pour ceux qui chargent les objets référents ou la zone : ils obtiendront le nouvel objet à la place, mais en chargeant l'objet, le serveur peut aussi indiquer que cet objet dispose de versions datées différentes et permettre d'effectuer une requête pour charger ces autres versions datées à la demande. Dans JOSM on aurait alors en dessous de la liste des attributs ou membres une autre liste en table mentionnant une liste d'autres IDs d'objets de même nature de primitive (noeud/chemin/relation), avec 3 colonnes : ID des autres objets, date de début, date de fin, cette liste étant ordonnée et mettant en gras la version actuelle dont les attributs et membres sont affichés. Si on clique une des lignes de cette table, on sélectionne le nouvel objet. On doit aussi pouvoir sélectionner plusieurs lignes pour effectuer ou pas des fusions d'attributs ou membres communs. Ce sera un peu plus compliqué pour les noeuds membres d'un chemin car ils sont ordonnés et connectés : il peut y avoir des noeuds communs entre deux versions d'un chemin, ou bien tous les noeuds différents, ou tous identiques, les chemins ne différent que par les attributs voire sans aucune autre différence que les dates de validité (par exemple quand deux anciens chemin pour une zone ont été fusionnés puis rescindés à nouveau, ou quand une ligne de transport est aménagée pendant un certain temps différemment, puis restaurée à son ancien état, ou quand deux communes fusionnent pendant un certain temps puis se reséparent, la commune ayant cessé d'exister de façon autonome pendant une période donnée ; cependant je pense qu'il sera rare que la restauration soit totalement à l'identique, sauf si la version intermédiaire n'était que temporaire pour durer que quelques mois ou moins de 2 ou 3 ans ; mais là tout est possible, et il est probable que l'ancienne version ne corresponde pas exactement à ce qu(on trouve à l'heure actuelle et que celle-ci de toute façon conservera un ID séparé demandant des corrections et contributions distinctes à ne pas apporter à la version actuelle). Il est aussi très probable que les anciennes versions n'aient pas le niveau de précision géométrique des versions actuelles : la Terre bouge, les rivières bougent, les terrains bougent, il y a des inondations, des glissements de terrain, des arrangements légaux pour certaines parties, des échanges de parcelles qui ne feront pas l'objet de retour en arrière. Le 4 janvier 2013 20:55, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Même après avoir lu les slides, m'est avis qu'il vaut mieux gérer ça au niveau de la primitive plutôt que ses tags... Le tags sont des données particulières de la primitive, gérer un historique à ce niveau c'est se condamner à devoir le refaire pour toute autre donnée rattachée à l'objet. Qu'on appelle ça une version ou autre chose, c'est nettement plus navigable et manipulable que d'avoir à parser des chaines de texte pour faire une sélection. La version a le mérite de relier logiquement plusieurs historiques du même objet sans avoir à créer une liaison history justement. Dans ce cas on aurait un entier supplémentaire au lieu d'une table avec plusieurs entiers nécessaires. Ce qui m'interpelle aussi,
Re: [OSM-talk-fr] Libération couche occupation du sol et Ortho-Photos aériennes de la réserve naturelle des Hauts plateaux du Vercors
Le 04/01/2013 22:24, Cyrille Giquello a écrit : Excellent. Encore merci Jean-Guilhem. Je ne sais pas générer les données nécessaires sur http://josm.openstreetmap.de/wiki/Maps pour ajouter cette orthophoto à la liste des imageries disponibles dans JOSM. Ca ne doit pas être bien compliqué. Il doit bien y avoir un p'tit script quelque part ? Cyrille. Il y a un plugin pour JOSM : https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery-XML-Bounds ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Niveau de landuse
Bonjour, j'ai suivi effectivement votre méthode, et j'obtient ainsi ceci, en m'étant inspiré de ma connaissance terrain et des données du registre parcellaire. http://www.openstreetmap.org/?lat=50.5979lon=2.8193zoom=14layers=M http://www.openstreetmap.org/?lat=50.5979lon=2.8193zoom=14layers=M Autre chose : Corine Land Cover est utilisé en fond sur la carte, n'y a-t-il pas possibilité de supprimer cette donnée sur le territoire de la commune, et comment faire ? J'ai du coup retracé les landuse par dessus. Hélène PETIT wrote Le 14/07/2012 13:17, SylvainH a écrit : Est-ce possible de mettre du landuse=residential pour une ou deux maisons isolés (ou vaut-il mieux laisser en farm) ? (exemple, sur la rue de Verdun, sur mon lien précédent). Il y a beaucoup de coins comme ça dans les communes que je cartographie, par exemple ici : http://www.openstreetmap.org/?lat=43.48037lon=1.58966zoom=15layers=M Je dessine les limites de landuse comme ce que je vois sur le terrain, en m'aidant si nécessaire du cadastre ou de bing quand il n'est pas raisonnable d'aller faire des relevés GPS dans la terre glaise ; ça fait des découpages très morcelés, mais c'est la représentation fidèle du terrain. Ensuite, techniquement, je m'arrange pour ne pas faire d'inclusions, je fais coller les landuse entre eux aux niveaux des routes ; Je trouve ça plus facile quand il faut maintenir : c'est nous il y a tout le temps de nouveaux lotissements. Le pavage de landuse est une question récurrente difficile, Cf : http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin paragraphe : Mes questions non résolues Pavage de landuse (20 Août 2010) Amicalement, Hélène ___ Talk-fr mailing list Talk-fr@ http://lists.openstreetmap.org/listinfo/talk-fr -- View this message in context: http://gis.19327.n5.nabble.com/Niveau-de-landuse-tp5716629p5742854.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Meilleur méthode pour créer une carte thématique
Bonsoir, Après plusieurs tests, j'ai constaté par rapport à ce que je souhaitais faire, qu'il était mieux d'utiliser Maperitive, et de stocker directement les tuiles sur un serveur web (travaillant à l'échelle d'une commune). L'avantage étant aussi de produire des tuiles à un instant t de la base et ainsi, mettre à jour manuellement ces tuiles (donc maîtrise du contenu et des mises à jour apparaissant sur la carte créée). -- View this message in context: http://gis.19327.n5.nabble.com/Meilleur-methode-pour-creer-une-carte-thematique-tp5714351p5742855.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
On a l'air d'être sur une longueur d'onde plus commune :) Cependant, et ca doit aller dans le sens d'Ista Pouss, il faut trouver une solution générale et reproductible à de multiples situations. Pour toute primitive, hormis les champs id, version, changeset, user, éventuellement les dates, tout n'est que donnée. Si il y a une modification = une nouvelle version est créée. Il faut partir de là et ne pas prendre les tags pour ce qu'ils ne sont pas. Les sources, les noms, comme les informations terrain, restent des données pour la base et l'API. Il n'y a pas de raison d'établir des critères dessus pour gérer non seulement les versions et par extension le système d'historique. Un objet (chaque version d'une primitive) est atomique et on ne peut pas le morceler. Sinon on ne peut pas s'assurer correctement de l'intégrité et de la requêtabilité du bazar. Si le système est suffisamment général, qui peut le plus peut le moins, on pourra adopter certains fonctionnements qui sont propres aux cas particuliers soulevés ici. Sinon ca va marcher, mais il faudra faire de constantes adaptations pour aller toujours plus loin dans le détail (vu le potentiel d'une communauté comme celle d'OSM). Et quelque chose de tout à fait intéressant dans ce que dit Philippe est que lorsque l'on prononce l'archivage d'un objet, toutes les versions intermédiaires qui le constituent jusque là sont regroupées en une seule (ça a sa limite : un tel archivage ne peut pas être annulé au delà de la dernière version connue). Enfin c'est ma vision des choses, j'ai implémenté un tel système directement sous la forme d'un ORM et certaines de ces problématiques se sont présentées. La leçon que j'en tire c'est qu'il faut s'abstenir de donner aux champs un sens particulier. Il en faut un minimum (id, changeset, version...) et gérer le reste de manière transparente. Un petit exemple avec ça : http://www.infos-reseaux.com/apps/ADSLObs/dataPLayout/props/com.infosReseaux.common.networks.IPNode/?obj_id=24314 Pour les dates j'aime bien les timestamp unix en secondes. Ca permet de traiter des entiers plutôt que des chaines de texte mais après c'est très personnel. Le 4 janvier 2013 22:26, Philippe Verdy verd...@wanadoo.fr a écrit : A mon avis la création d'une version historique ne va pas entrainer une profusion de données. Le plus gros des modifs de versions est dans la branche principale (celle de la version actuelle, et cela restera celle qui sera le plus contribuée. A un instant donnée on ne crée un objet historique que pour conserver une de ces versions à peu près stable. D'autant plus qu'on peut faire en sorte que l'éditeur par défaut ne charge pas ces objets historiques sauf si on en fait la demande explicitement. Je suis d'accord avec toi que mettre cela dans des tags standards n'est pas la bonne solution et qu'il vaut mieux une primitive séparée pour créer une méta-relation listant les objets liés à un même intervalle historique daté. Un même id d'objet ne doit servir qu'à un seul intervalle de validité de date, cet objet pouvant être chargé ou pas (mais pas par défaut par l'API quant on ne précise pas une date de validité ou qu'on ne précise pas un intervalle de date à rechercher ou pas de requête pour charger toutes les dates. Ce sera d'autant plus important que pour les versions historiques, se posera la question des sources différentes, et de droits intellectuels distincts, des problèmes de licences distinctes. Imaginons ensuite qu'on veuille créer une nouvelle version historique d'un objet actuel pour en garder une archive datée, on devrait avoir un bouton permettant d'ajouter cette version en mentionnant seulement la date de fin de l'objet actuel et de début du nouvel objet. Les deux objets sont alors soumis au serveur. L'ancien objet change de statut (il est modifié) ce qui oblige les autres éditeurs à en tenir compte comme une modif puisque l'ancien objet sera versionné comme une modif standard. Mais il deviendra invisible ensuite pour ceux qui chargent les objets référents ou la zone : ils obtiendront le nouvel objet à la place, mais en chargeant l'objet, le serveur peut aussi indiquer que cet objet dispose de versions datées différentes et permettre d'effectuer une requête pour charger ces autres versions datées à la demande. Dans JOSM on aurait alors en dessous de la liste des attributs ou membres une autre liste en table mentionnant une liste d'autres IDs d'objets de même nature de primitive (noeud/chemin/relation), avec 3 colonnes : ID des autres objets, date de début, date de fin, cette liste étant ordonnée et mettant en gras la version actuelle dont les attributs et membres sont affichés. Si on clique une des lignes de cette table, on sélectionne le nouvel objet. On doit aussi pouvoir sélectionner plusieurs lignes pour effectuer ou pas des fusions d'attributs ou membres communs. Ce sera un peu plus compliqué pour les noeuds membres d'un chemin car ils sont ordonnés et connectés
Re: [OSM-talk-fr] Stand OpenStreetMap FOSDEM 2013
J'ai ajouté la présence du stand à l'agenda de Openstreetmap: http://wiki.openstreetmap.org/wiki/Current_events Salutations cordiales, Jo 2012/12/26 RatZilla$ ratzil...@gmail.com J'ai reçu la confirmation du comité d'organisation du Fosdem. En route pour Bruxelles première étape avant notre rencontre nationale. Il nous faut réfléchir au matériel et supports de com à ramener (Kakemono, flyers et goodies) Nous pouvons profiter de La Cantine et de La Fonderie pour les conseils et le support sur ces questions Gaël 2012/12/6 Florian LAINEZ winner...@free.fr Il se peut que j'y sois (oui je sais réponse de m). Je vous tiens au jus de coco Le 6 décembre 2012 08:10, Cyrille Giquello cyrill...@gmail.com a écrit : Le 4 décembre 2012 10:48, RatZilla$ ratzil...@gmail.com a écrit : Bonjour à tou[te]s, J'ai réservé un stand OSM au FOSDEM 2013 qui se déroulera le samedi 2 et dimanche 3 février 2013 à Bruxelles. https://fosdem.org/2013/ Qui y va ? Hop, réservé. -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* http://twitter.com/overflorian http://www.nouslesgeeks.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
On dérive (comme les continents, on va bientôt en parler)... c'est intéressant de pousser les concepts à leur limite, mais si on pouvait identifier des cas simples qu'on peut gérer avec des solutions simples ça serait déjà pas mal, non ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Données historique et historiques des données...
Je ne connais pas les cas simples, juste des cas particuliers. On peut faire un truc simple pour commencer qui sera possiblement une véritable horreur à intégrer à la prochaine itération en plus de ne concerner qu'un nombre restreint de situations. Après je ne fais pas (encore, qui sait) parti de l'équipe de dev des outils OSM, peut-être qu'ils ont un autre angle d'approche du problème que je serais ravi de lire. Le 5 janvier 2013 00:29, Christian Quest cqu...@openstreetmap.fr a écrit : On dérive (comme les continents, on va bientôt en parler)... c'est intéressant de pousser les concepts à leur limite, mais si on pouvait identifier des cas simples qu'on peut gérer avec des solutions simples ça serait déjà pas mal, non ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Niveau de landuse
Le 04/01/2013 23:39, SylvainH a écrit : Bonjour, j'ai suivi effectivement votre méthode, et j'obtient ainsi ceci, en m'étant inspiré de ma connaissance terrain et des données du registre parcellaire. http://www.openstreetmap.org/?lat=50.5979lon=2.8193zoom=14layers=M http://www.openstreetmap.org/?lat=50.5979lon=2.8193zoom=14layers=M Autre chose : Corine Land Cover est utilisé en fond sur la carte, n'y a-t-il pas possibilité de supprimer cette donnée sur le territoire de la commune, et comment faire ? J'ai du coup retracé les landuse par dessus. Superbe travail ! Une petite remarque : contrairement à certains (que je ne nommerai pas pour ménager des susceptibilité et éviter du troll), je n'aime pas, j'ai horreur de tracer les limites de parcelles sur la voirie : l'axe de la voie n'a jamais été une limite de champs ou de forêt. Les deux limites sont donc fausses. Je place la limite d'un côté ou de l'autre de la voie, comme ça, j'en ai un qui est bon. Entre residential et quelque-chose, je mets la voie dans le residential. Entre foret et quelque-chose, j'évite la voie dans le couvert. Par exemple le camps de caravanes Camps des Roses ne se finit pas au milieu de la rue. Et dans sa partie Ouest, il eut mieux valu faire la limite sur la haie de la prairie pour tracer cette haie. Aubers est maintenant extrait du multipolygone farm, qui a été redécoupé à l'occasion. Pour continuer, on peut caractériser les bâtiments : building=house|garage|appartment... Certes, ça ne se voit pas beaucoup sur la carte. Mais on ne taggue pas pour le rendu, n'est-ce pas ? -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
