[OSM-talk-fr] Polygone Corine bizarre
Sur la commune de La Châtelaine (Jura), le polygone landuse=residential issu de Corine Land Cover est bizarre, comme s'il avait été élargi (zone tampon ou buffer), avec des coins arrondis : http://osm.org/go/0CRMTpKZ J'ai vérifié sur http://sd1878-2.sivit.org où se trouvent les données originales et le polygone est déjà dans cet état là dans Corine. Y a-t-il d'autres exemples de cet effet arrondi ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Don de matériel de la fondation Fr ee
Pieren a écrit : De plus, si le serveur de fichier n'a pas besoin de grosses capacités, un serveur de tuile nécessite une machine beaucoup plus costaude que ce qui est proposé ici. Quelles devraient être alors la capacité de la machine pour assurer un service de tuiles fluide (à l'instar des serveurs google maps) ? Peut-on connaitre le trafic quotidien des tuiles sur le serveur OSM ? Y a-t-il des stats officielles publiques ? /Lapi ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Don de matériel de la fondation Fr ee
Lapinos03 a écrit : Pieren a écrit : De plus, si le serveur de fichier n'a pas besoin de grosses capacités, un serveur de tuile nécessite une machine beaucoup plus costaude que ce qui est proposé ici. Quelles devraient être alors la capacité de la machine pour assurer un service de tuiles fluide (à l'instar des serveurs google maps) ? Peut-on connaitre le trafic quotidien des tuiles sur le serveur OSM ? Y a-t-il des stats officielles publiques ? http://munin.openstreetmap.org/ -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Polygone Corine bizarre
Damouns a écrit : Sur la commune de La Châtelaine (Jura), le polygone landuse=residential issu de Corine Land Cover est bizarre, comme s'il avait été élargi (zone tampon ou buffer), avec des coins arrondis : http://osm.org/go/0CRMTpKZ J'ai vérifié sur http://sd1878-2.sivit.org où se trouvent les données originales et le polygone est déjà dans cet état là dans Corine. Y a-t-il d'autres exemples de cet effet arrondi ? Ça sent le gros pinceau (diamètre : beaucoup de pixels) dans l'outil de dessin. -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] tag source dacastre
Bonsoir, Je m'apprête à modifier les tags sources du cadastre pour renseigner l'année. C'est pas optimal mais c'est mieux que rien. Je posterai les logs de la version d'essai demain. Je me posait une question sur le point virgule dans cette source. Usuellement le ';' est utilisé comme séparateur pour des champs ayant plusieurs valeurs. Ici il est utilisé à l'intérieur d'une valeur... ce qui n'est pas très pratique. Est-ce qu'on laisse comme ça ou on change en lui votant un remplaçant ? Actuellement le champ ressemble à : value cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre ; mise à jour : 2009 /value -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag source dacastre
Etienne Chové a écrit : Bonsoir, Je m'apprête à modifier les tags sources du cadastre pour renseigner l'année. C'est pas optimal mais c'est mieux que rien. Je posterai les logs de la version d'essai demain. Je me posait une question sur le point virgule dans cette source. Usuellement le ';' est utilisé comme séparateur pour des champs ayant plusieurs valeurs. Ici il est utilisé à l'intérieur d'une valeur... ce qui n'est pas très pratique. Est-ce qu'on laisse comme ça ou on change en lui votant un remplaçant ? Actuellement le champ ressemble à : value cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre ; mise à jour : 2009 /value Je voterai bien pour source=Direction Générale des Finances Publiques - Cadastre. Mise à jour : année Pour les bâtiments, année pourrait valoir la date de dernière mise à jour en CDIF. Ce n'est pas uniquement un souci de précision, mais aussi un indicateur pour des contributeurs futurs qui tomberaient sur une feuille cadastrale plus récente. Ils sauraient, de suite, s'il y a lieu d'investiguer sur des mises à jour de bâti. Chacun fera comme il le sent. Si j'ai bien compris le robot (j'ai lu mon Asimov), le côté génant vient plus du '' que de la syntaxe de la mention de source ? Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag source dacastre
Denis a écrit : Etienne Chové a écrit : Bonsoir, Je m'apprête à modifier les tags sources du cadastre pour renseigner l'année. C'est pas optimal mais c'est mieux que rien. Je posterai les logs de la version d'essai demain. Je me posait une question sur le point virgule dans cette source. Usuellement le ';' est utilisé comme séparateur pour des champs ayant plusieurs valeurs. Ici il est utilisé à l'intérieur d'une valeur... ce qui n'est pas très pratique. Est-ce qu'on laisse comme ça ou on change en lui votant un remplaçant ? Actuellement le champ ressemble à : value cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre ; mise à jour : 2009 /value Je voterai bien pour source=Direction Générale des Finances Publiques - Cadastre. Mise à jour : année Pour les bâtiments, année pourrait valoir la date de dernière mise à jour en CDIF. Ce n'est pas uniquement un souci de précision, mais aussi un indicateur pour des contributeurs futurs qui tomberaient sur une feuille cadastrale plus récente. Ils sauraient, de suite, s'il y a lieu d'investiguer sur des mises à jour de bâti. Chacun fera comme il le sent. Si j'ai bien compris le robot (j'ai lu mon Asimov), le côté génant vient plus du '' que de la syntaxe de la mention de source ? Le robot mettrait 2009 pour tout le monde qui a encore . L'année dernière on s'était dit qu'il fallait faire un truc mieux, mais ça n'a jamais été fait. C'est sûr que 2009 n'est pas le mieux et va introduire des faux mais au moins on sait que c'est 'au plus 2009', et quand on aura des planches postérieures à 2009 on pourra se dire qu'on peut faire une màj. Si on laisse les , on ne saura jamais quand faire de màj. Le problème du ; est que pour un robot/éditeur... c'est difficile de savoir ou couper pour avoir la liste des source. Normalement on devrait couper au ; ce qui lui donne deux sources : 1. cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre 2. mise à jour : 2009 Je me suis dit que quitte à faire 1 million de modifs sur la base, autant réfléchir un peu avant et voir si on peut pas faire d'autres choses en même temps; d'où ma réflexion sur les ; -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tag source dacastre
Etienne Chové a écrit : Le problème du ; est que pour un robot/éditeur... c'est difficile de savoir ou couper pour avoir la liste des source. Normalement on devrait couper au ; ce qui lui donne deux sources : 1. cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre 2. mise à jour : 2009 Les robots ne sont pas humains et vice-versa. A nous la créativité et aux robots les emmerdements ;-) Je me suis dit que quitte à faire 1 million de modifs sur la base, autant réfléchir un peu avant et voir si on peut pas faire d'autres choses en même temps; d'où ma réflexion sur les ; Promis, je vais faire gaffe aux ;. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] représentation d'une limite comm unale
Bonjour, Je souhaiterais savoir comment représenter une entité linéaire qui est à la fois une limite communale et un élément naturel du paysage (rivière, falaise ...) Ex la limite entre deux communes est une rivière Faut-il dupliquer le trait ? Ou mettre plusieurs attributs sur l'entité? Merci Arnaud ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] représentation d'une limite commun ale
Sujet paru plusieurs fois sur la liste et documenté sur le wiki, en gros tu as le choix : http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tracer_les_limites_administratives#Limites_administratives_utilisant_des_.C3.A9l.C3.A9ments_physiques 2009/11/9 Arnaud Vandecasteele arnaud@gmail.com Bonjour, Je souhaiterais savoir comment représenter une entité linéaire qui est à la fois une limite communale et un élément naturel du paysage (rivière, falaise ...) Ex la limite entre deux communes est une rivière Faut-il dupliquer le trait ? Ou mettre plusieurs attributs sur l'entité? Merci Arnaud ___ 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] représentation d'une limite comm unale
Arnaud Vandecasteele a écrit : Bonjour, Je souhaiterais savoir comment représenter une entité linéaire qui est à la fois une limite communale et un élément naturel du paysage (rivière, falaise ...) Ex la limite entre deux communes est une rivière Faut-il dupliquer le trait ? Ou mettre plusieurs attributs sur l'entité? Merci Arnaud Bonsoir, Il y a eu déjà une réponse à cette question ces jours-ci. Je cite le fil. Aurelien Jacobs a écrit : On Sun, Nov 08, 2009 at 11:03:29AM +0100, Pieren wrote: 2009/11/8 Arnaud Vandecasteele arnaud@gmail.com: Bonjour, Je souhaiterais savoir comment représenter une entité linéaire qui est à la fois une limite communale et un élément naturel du paysage (rivière, falaise ...) Ex la limite entre deux communes est une rivière Faut-il dupliquer le trait ? Ou mettre plusieurs attributs sur l'entité? Merci Arnaud La réponse se trouve dans la partie discussion de cette magnifique page du wiki: http://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Tracer_les_limites_administratives#Limites_administratives_utilisant_des_.C3.A9l.C3.A9ments_physiques Sachant que la proposition 2 sur cette page n'est pas utilisable. Cette proposition suggère par example de tagger un way comme ça : waterway=river boundary=administrative name=blablabla Il n'est alors plus possible de savoir si blablabla est le nom de la rivière ou bien celui de la limite administrative (ou des deux). Les données seront exploitées de manière inconsistantes selon le soft qui les exploite. J'ai pris l'exemple du tag name=* mais ça s'applique probablement à d'autres tag qui on un sens à la fois pour les waterway et les boundary. Je suggère que cette proposition soit supprimée du wiki. Aurel - -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Timezone
Bonjour, bonsoir. Y a-t-il une implémentation des timzeones dans OSM ? http://home.tiscali.nl/~t876506/TZworld.html Je travaille sur tout autre chose (lié au temps, pas à la géographie) et je suis tombé par hasard sur ça : http://efele.net/maps/tz/us/ http://efele.net/maps/tz/world/ J'ai fait une recherche rapide dans le wiki : http://wiki.openstreetmap.org/index.php?title=Special:Searchsearch=timezone rien de probant. Dans les relations France : http://www.openstreetmap.org/browse/relation/11980 http://www.openstreetmap.org/browse/relation/79981 Rien. Ça n'aurait pas sa place dans un jeu de tag ? Voici le code en iCalendar du timezone en vigueur chez les Français : BEGIN:VTIMEZONE TZID:Europe/Paris X-LIC-LOCATION:Europe/Paris BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T02 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T03 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE Ça pourrait donner : timezone=cet;cest timezone:cet:offset=+1:00 timezone:cet:dtstart=19700329T02 timezone::cet:rrule=freq:yearly;interval:1;byday:-1su;bymonth:10 timezone:cest:offset=+2:00 timezone:cest:dtstart=19701025T03 timezone::cest:rrule=freq:yearly;interval:1;byday:-1su;bymonth:3 Les machines pourraient alors savoir comment calculer les indications d'heure (openning_hour...), si elles ont l'algorithme qui va bien... -- Vincent alias FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] surveiller un debutant
Pieren a écrit : 2009/11/7 hamster hams...@suna.fdn.fr: * quand un batiment couvre plusieurs parcelles cadastrales (typiquement un pate d'immeubles en ville) vaut-il mieux considerer qu'a chaque parcelle il y a un batiment ou bien que le bloc continu fait un seul batiment qui s'etends sur plusieurs parcelles ? en gros quel est l'interet de differentier les morceaux d'immeubles selon les parcelles cadastrales, sachant en plus que c'est des fois faux : il arrive que par exemple un copropriete soit proprietaire de plusieurs parcelles et donc l'immeuble qui est dessus ces parcelles n'a pas a etre coupe en morceaux Il est très, très fréquent qu'un bâtiment chevauche plusieurs parcelles. Une des raisons est que fusionner des parcelles a un coût et que cela ne rapporte rien. Donc, non il ne faut découper les bâtiments en fonction des parcelles mais, comme tu dis, en fonction de la continuité du bâtiment. j'en ai fait un peu comme ca : http://www.openstreetmap.org/?lat=44.93079lon=2.44858zoom=17layers=B000FTF c'est nettement plus rapide a dessiner mais ca m'etonne un peu parce que c'est pas du tout ce qui a ete fait a grenoble (dont je me suis servi d'exemple) de plus ca oblige a tout le temps mettre les n° sur des points et non pas sur des surfaces : est-ce un bien ? personnellement je n'aime pas le rendu ou le n° est au milieu d'une zone et non pas au bord de la route, mais c'est tres subjectif * sur le cadastre il y a 2 tons de couleur : orange fonce pour les batiments, et orange clair pour les preaus, auvents, appentis, cabanons, etc quelle est la politique vis a vis de ces zones claires ? on les considere comme des constructions et on les dessine ou on les ignore ? Le sujet n'est pas tranché. Il n'existe pas de tag officiel pour les structures qui ne sont pas des bâtiments fermés (toits, hangars, terrasses, balcons), ni pour les bâtiments souterrains (il y a une proposition récente sur le wiki pour cette deuxième caétgorie : http://wiki.openstreetmap.org/wiki/Proposed_features/covered en cours de discussions). L'import du cadastre de Brest ajoute un tag pour les différencier mais je ne sais plus les détails et c'est non-officiel. Personnellement, j'ai opté pour les tagguer de la même manière qu'un bâtiment, quitte à repasser plus-tard pour changer le tag ou en ajouter un supplémentaire. Cela représente finalement assez peu de polygones en plus et cela m'évitera de revenir faire du dessin. Cela se rapproche aussi des usages de nos collègues étrangers qui n'ont souvent que des images vues du ciel à disposition pour tracer les bâtiments et qui ne peuvent pas faire la différence comme nous sans aller sur place. j'ai dessine independamment pour pas avoir a modifier plus tard si on veut differencier j'ai pas reussi a faire pour un trou dans un immeuble qui est covered j'ai fait un multipolygon dans lequel le trou est en inner et avec lui meme le tag building=yes, mais au rendu ca sort comme un trou tout simple ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] représentation d'une limite comm unale
Bonjour à tous, Merci pour vos réponses et désolé pour le doublon. Le fait est que, même si vous m'aviez répondu, je n'avais reçu aucun mail de la liste OSM suite à ma 1er question. J'ai donc pensé qu'il n'avait pas été envoyé. C'est pour cela que je m'étais permis de relancer. Le wiki propose 3 méthodes. Même si elles sont toutes acceptables, laquelle est la plus généralement utilisée? Merci Arnaud ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
