Re: [OSM-talk-fr] Comment augmenter le nombre de noms de commune affichés pour un certain niveau de zoom ?
Je pense qu'il faut modifier le style de carte, ce doit-être possible chez Cloudmade: http://maps.cloudmade.com/editor Yves Le 12/02/2012 22:26, Stephane Klein a écrit : Bonjour, j'aimerais pourvoir augmenter le nombre de noms de commune affichés à un certain niveau de zoom. Par exemple, sur cette carte http://projects.stephane-klein.info/maps/index2.html dont le niveau zoom est de 12 il y a plus de noms de commune indiqués que sur cette carte http://projects.stephane-klein.info/maps/index2.html dont le niveau zoom est de 11. J'aimerais afficher sur la carte avec un niveau de zoom de 11 autant de noms de commune que sur la carte avec un niveau de zoom de 12. Est-ce que c'est possible ? Si oui avez vous un lien vers une doc ? un exemple ? Merci d'avance pour votre aide. Cordialement, Stéphane ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)
Le 12 févr. 2012 à 18:12, Pieren a écrit : > Je dirais même plus : > est bâtiment tout ce qui est building=* à l'exclusion de building=no > (cela m'est arrivé de le mettre sur du bâti qui n'existe que dans le > cadastre mais que j'ai quand même conservé dans OSM avec une "note" > pour expliquer. Et je ne crois pas être le seul à avoir pratiqué cette > méthode) Ce problème (ainsi que d'autres) est maintenant corrigé dans la version 0.2. Enjoy, Jérôme ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Servir des MBTiles de TileMill en PHP (était Carte Power (était Gare de péage, frais de péage etc...))
On 07/02/2012 00:02, Frédéric Rodrigo wrote: On 06/02/2012 09:28, Bruno Cortial wrote: A fond sur tilemill je vois :-) Pour afficher/servir les tuiles des MBtiles il y a du python (django) sur le site de développement [1] , mais pour un hébergement "standard" il y a un bout de php qui fonctionne [2] Par contre je n'ai pas trouvé de code php pour servir la couche "feature" (UTFgrid) que tilemill peut générer dans le fichier MBTile. Effectivement je n'avais pas vu qu'il y avait aussi ces infos dans le fichier. Pour ce qui est de les servir j'ai fait ça : http://osm7.pole-aquinetic.fr/~fred/power/mbtiles-utfgrid.php.txt Par contre pour les utiliser c'est bien une autre histoire. Il faut utiliser http://mapbox.com/wax/ Coté OpenaLyer la doc est plutôt légère ! Frédéric. Comme ça avait quand même l'air assez intéressant de pouvoir afficher toutes les données des MBTiles, les tiles, mais aussi les descriptions des éléments, j'ai codé un script PHP qui sert à la fois les tiles PNG et aussi les tiles UTFGrid. Pour que ça fonctionne avec le client Wax de MapBox, j'ai quand même du mettre les mains dans le cambouis et faire du reverse engineering. Mais au final ça marche ! J'explique tout ça sur mon (tout nouveau) blog : http://blog.carte-libre.fr/index.php?post/2012/02/12/Serve-all-MBTtile-features-with-PHP-script -- Frédéric Rodrigo Carte-Libre Néogéographie, web mappeur indépendant 06 89 55 75 42 http://carte-libre.fr/ - frede...@carte-libre.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Comment augmenter le nombre de noms de commune affichés pour un certain niveau de zoom ?
Bonjour, j'aimerais pourvoir augmenter le nombre de noms de commune affichés à un certain niveau de zoom. Par exemple, sur cette carte http://projects.stephane-klein.info/maps/index2.html dont le niveau zoom est de 12 il y a plus de noms de commune indiqués que sur cette carte http://projects.stephane-klein.info/maps/index2.html dont le niveau zoom est de 11. J'aimerais afficher sur la carte avec un niveau de zoom de 11 autant de noms de commune que sur la carte avec un niveau de zoom de 12. Est-ce que c'est possible ? Si oui avez vous un lien vers une doc ? un exemple ? Merci d'avance pour votre aide. Cordialement, Stéphane -- Stéphane Klein blog: http://stephane-klein.info Twitter: http://twitter.com/klein_stephane pro: http://www.is-webdesign.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Périphérique nord-ouest de Tours
Le 12/02/2012 19:03, simon a écrit : Le vendredi 10 février 2012 10:01:15, Vincent de Chateau-Thierry a écrit : Bonjour, Ce mail est potentiellement pour local-to...@listes.openstreetmap.fr :-) ou o...@libre.cc http://wiki.openstreetmap.org/wiki/Tours#Liste_de_diffusion noté ! En regardant ce document sur le site du CG37 : http://www.cg37.fr/periph/pdf/plan-general-presentation-2006.pdf la sortie du "diffuseur de Fondettes" en direction de Fondettes (la D 367) est tracé comme passant sous le périphérique, puis sous la voie ferrée. Dans OSM : http://www.openstreetmap.org/?lat=47.41766&lon=0.63591&zoom=17&layers=M on a une modélisation opposée : la D 367 passe au dessus du périphérique puis au dessus de la voie ferrée. Par ailleurs en venant du nord, les bretelles de sortie puis d'entrée ne peuvent accéder à la D367, en pont de part et d'autre du croisement : http://www.openstreetmap.org/browse/node/1445519838 N'étant pas dans le coin pour constater, est-ce que les régionaux de l'étape ont moyen de valider une des versions, et le cas échéant de mettre à jour la base ? merci vincent Correction effectuer, J'avais tracer la route au débute des travaux sur la base des photos de Tour(s) Plus http://wiki.openstreetmap.org/wiki/Tours/Ortophoto , et malheureusement j'avais mal interprété malgré que l'on voit clairement que la voie passe sous la voie de chemin de fer. Le pire c'est que j'y passe deux fois par jour :D Merci Simon. @ Cyrille : 2 jours entre le signalement et la correction, pas de quoi s'inquiéter pour la réputation d'OSM :-) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Bonsoir, Le 12/02/2012 11:59, Vincent Pottier a écrit : Et bien c'est typiquement ça : tagguer pour le rendu ! Un nom en l'air qui ne se rapporte à rien d'autre qu'à un segment ! Et c'est quoi ce segment ? Un morceau d'autoroute ? Un mur de centrale nucléaire en construction ? Une ligne haute tension ? Un oued ? Si ça avait été un point, une surface... ça aurait qualifié un lieu, une aire... Mais là, avec un segment de droite... ça indique tout sauf le nom d'un lieu ! Aucun logiciel ne peut tirer parti de ça sérieusement. Et j'espère que beaucoup l'éliminent dans la chaîne de traitement. Si l'affichage des nom de lieu ne convient pas sur mapnik, c'est mapnik qu'il faut changer, pas la façon d'entrer l'information dans la base. +1 sur toute la ligne (tout le segment ?) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)
Le 12/02/2012 18:12, Pieren a écrit : 2012/2/10 Etienne Trimaille: Est-ce possible de prendre en compte les building=* en compte ? Ahem… je dois avouer piteusement en public que je n'avais pas connaissance de ces variations sur tag building. Et donc… les bâtiments qui sont en building=XX ou XX n'est pas yes sont complètement ignorés de la comparaison! (arg) Il n'existe pas que le building=yes ;-) http://wiki.openstreetmap.org/wiki/Key:building Je dirais même plus : est bâtiment tout ce qui est building=* à l'exclusion de building=no (cela m'est arrivé de le mettre sur du bâti qui n'existe que dans le cadastre mais que j'ai quand même conservé dans OSM avec une "note" pour expliquer. Et je ne crois pas être le seul à avoir pratiqué cette méthode) Pieren Humm, j'espère que tu crois ne pas être le seul, ne penses-tu pas ? 0.01 € (et encore ;-) -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] iPad en test
Bonsoir, Je ne me souviens pas en avoir vu une qui y ressemble... Peut être open maps s'y rapprochera un peu... Le dimanche 12 février 2012, Romain MEHUT a écrit : > Bonsoir, > > J'ai un iPad en test pendant une semaine. Est-ce que vous auriez une application à me conseiller pour recueillir des données comme à la façon d'un walking-paper? Je précise que je n'ai pas de connexion internet si ce n'est via le wifi. > > Merci. > > Romain > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Périphérique nord-ouest de Tours
Le vendredi 10 février 2012 10:01:15, Vincent de Chateau-Thierry a écrit : > Bonjour, > Ce mail est potentiellement pour local-to...@listes.openstreetmap.fr :-) > ou o...@libre.cc http://wiki.openstreetmap.org/wiki/Tours#Liste_de_diffusion > En regardant ce document sur le site du CG37 : > http://www.cg37.fr/periph/pdf/plan-general-presentation-2006.pdf > la sortie du "diffuseur de Fondettes" en direction de Fondettes (la D 367) > est tracé comme passant sous le périphérique, puis sous la voie ferrée. > > Dans OSM : > http://www.openstreetmap.org/?lat=47.41766&lon=0.63591&zoom=17&layers=M > on a une modélisation opposée : la D 367 passe au dessus du périphérique > puis au dessus de la voie ferrée. Par ailleurs en venant du nord, les > bretelles de sortie puis d'entrée ne peuvent accéder à la D367, en pont de > part et d'autre du croisement : > http://www.openstreetmap.org/browse/node/1445519838 > > N'étant pas dans le coin pour constater, est-ce que les régionaux de > l'étape ont moyen de valider une des versions, et le cas échéant de mettre > à jour la base ? > > merci > vincent > Correction effectuer, J'avais tracer la route au débute des travaux sur la base des photos de Tour(s) Plus http://wiki.openstreetmap.org/wiki/Tours/Ortophoto , et malheureusement j'avais mal interprété malgré que l'on voit clairement que la voie passe sous la voie de chemin de fer. Le pire c'est que j'y passe deux fois par jour :D ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] iPad en test
Bonsoir, J'ai un iPad en test pendant une semaine. Est-ce que vous auriez une application à me conseiller pour recueillir des données comme à la façon d'un walking-paper? Je précise que je n'ai pas de connexion internet si ce n'est *via *le wifi. Merci. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)
2012/2/10 Etienne Trimaille : >> > Est-ce possible de prendre en compte les building=* en compte ? >> Ahem… je dois avouer piteusement en public que je n'avais pas connaissance >> de ces variations sur tag building. Et donc… >> les bâtiments qui sont en building=XX ou XX n'est pas yes sont >> complètement ignorés de la comparaison! (arg) > Il n'existe pas que le building=yes ;-) > http://wiki.openstreetmap.org/wiki/Key:building > Je dirais même plus : est bâtiment tout ce qui est building=* à l'exclusion de building=no (cela m'est arrivé de le mettre sur du bâti qui n'existe que dans le cadastre mais que j'ai quand même conservé dans OSM avec une "note" pour expliquer. Et je ne crois pas être le seul à avoir pratiqué cette méthode) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
C'est vrai que Mapnik (enfin, la feuille de style d'osm) à une fâcheuse tendance à marquer tout les tags 'name='. Ici une relation route=piste, piste:type=nordic : http://www.openstreetmap.org/?lat=46.8070887029171&lon=6.37093037366867&zoom=18 S'il faut commencer à inventer des tags pour ne PAS apparaitre sur la carte ... Yves Le 12/02/2012 18:04, sly (sylvain letuffe) a écrit : Le dimanche 12 février 2012 11:59:24, Vincent Pottier a écrit : Et bien c'est typiquement ça : tagguer pour le rendu ! +1 A éviter donc ! Si ça avait été un point, une surface... ça aurait qualifié un lieu Heu, selon moi, même pas. quelque soit l'élément si il n'y a que le tag nom, genre : name=pré Je suis bien emmerdé pour savoir ce que c'est. Est-ce un pré et son créateur ne savait pas comment le rentrer ? est-ce le nom d'un lieu ? A la limite, si le hameau est rentré sous la forme d'un segment mais porte bien le place=hamlet, alors au moins on sait ce que c'est. Mais pas sans la tag place. Aucun logiciel ne peut tirer parti de ça sérieusement. Et j'espère que beaucoup l'éliminent dans la chaîne de traitement. Et j'en serais même presque à éliminer le problème à la source, ou en tout cas discuter avec le contributeur sur le pourquoi ce truc. Si l'affichage des nom de lieu ne convient pas sur mapnik, c'est mapnik qu'il faut changer, pas la façon d'entrer l'information dans la base. Ou ne pas l'utiliser, c'est pas les rendus qui manquent ! Il y a le choix ! Pour ma part, je considère le rendu mapnik comme un rendu pour les contributeurs, update rapide, beaucoup d'infos, pas pour les utilisateurs. Le rendu Mapquest ou d'autres, correspondent mieux selon moi à ceux qui veulent du joli pour le montrer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Le dimanche 12 février 2012 11:59:24, Vincent Pottier a écrit : > Et bien c'est typiquement ça : tagguer pour le rendu ! +1 A éviter donc ! > Si ça avait été un point, une surface... ça aurait qualifié un lieu Heu, selon moi, même pas. quelque soit l'élément si il n'y a que le tag nom, genre : name=pré Je suis bien emmerdé pour savoir ce que c'est. Est-ce un pré et son créateur ne savait pas comment le rentrer ? est-ce le nom d'un lieu ? A la limite, si le hameau est rentré sous la forme d'un segment mais porte bien le place=hamlet, alors au moins on sait ce que c'est. Mais pas sans la tag place. > Aucun logiciel ne peut tirer parti de ça sérieusement. Et j'espère que > beaucoup l'éliminent dans la chaîne de traitement. Et j'en serais même presque à éliminer le problème à la source, ou en tout cas discuter avec le contributeur sur le pourquoi ce truc. > Si l'affichage des nom de lieu ne convient pas sur mapnik, c'est mapnik > qu'il faut changer, pas la façon d'entrer l'information dans la base. Ou ne pas l'utiliser, c'est pas les rendus qui manquent ! Il y a le choix ! Pour ma part, je considère le rendu mapnik comme un rendu pour les contributeurs, update rapide, beaucoup d'infos, pas pour les utilisateurs. Le rendu Mapquest ou d'autres, correspondent mieux selon moi à ceux qui veulent du joli pour le montrer -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Le 12 février 2012 14:02, Hélène PETIT a écrit : > Le 12/02/2012 13:49, Philippe Verdy a écrit : > >> Le 12 février 2012 13:10, Hélène PETIT a écrit : >>> >>> ...où en est la modif de mapnik qui n'écrit pas le nom de la commune au >>> barycentre de la zone quand il y a un admin-centre dans la relation, >>> merci ? > > . > >> De plus ce n'est pas l'"admin_centre" qui détermine ça, puisque le nom >> de l'admin_centre est très souvent différent de celui de la zone >> définie par la relation, l'admin_centre mentionne le plus souvent le >> nom de la commune chef-lieu, et ne correspond à la relation QUE quand >> la relation est une commune (admin_level=8) : il n'y a que dans ce >> cas-là que les deux noms font alors (éventuellement) doublons. > > > Ben oui, hein, j'avais bien écrit "le nom de la commune" > Quand même ... Ya des fois, je me demande. Note bien le "éventuellement", car la correspondance n'est pas systématique non plus. Et note aussi le cas des communes éclatées en plusieurs parties (avec des exclaves) que j'ai expliqué, qui est le dernier cas où les labels sont affichés plusieurs fois. D'ailleurs si on était rigoureux, il n'y a aucune raison pour que le label de la relation de commune se positionne sur son "admin_centre", qui mentionne plutôt une mairie, souvent décentrée par rapport au territoire entier de la commune, et parfois même en dehors de son agglomération "principale", et qui peut avoir un nom plus qualifié que le seul nom de la commune. Et idéalement il n'y a même aucune raison que ce label qu'on positionnerait avec "admin_centre" soit placé exactement à la mairie (d'autant qu'elle peut avoir plusieurs emplacements dans la commune et peut aussi avoir déménagé en laissant une mairie annexe à son ancien centre historique qui est aussi mieux placé au centre bourg dans l'agglomération et au noeud de communication, et souvent aussi très proche voir en face de l'église historique du village, sur une place où ses situe aussi les commerces et services). Bref un label de commune (positionné avec admin_center) devrait se situer non pas à sa mairie mais sur sa place centrale, au centre du carrefour d'où partent les routes vers toutes les communes limitrophes, ou dans les communes plus grandes à la position de son principal centre administratif accueillant les services municipaux (ce n'est pas toujours l'hôtel de ville qui peut rester un bâtiment plus "prestigieux" pour les cérémonies, mais plus petit et pas adapté ou trop petit à recevoir tous les service municipaux). Cela n'empêche pas pour autant de "mapper" l'hôtel de ville dans la commune (pas nécessairement au même endroit), ainsi que les mairies annexes. Maintenant concernant les localisations de chef-lieux de zones plus grandes qu'une commune, il n'y a aucune raison pour qu'on utilise le noeud référencé par le rôle "admin_center" de la relation de commune, alors que le rôle "admin_center" de cette zone plus grande devrait mentionner la relation de la commune entière, où on trouve (par exemple) la préfecture de région ou de département ou la sous-préfecture, le siège d'une intercommunalité, mais aussi la capitale du pays (cette capitale de la France ce n'est PAS l'Hôtel de Ville de Paris, ni même aucune position précise dans Paris, mais l'emplacement regroupant toutes les institutions nationales qui y sont installées : la présidence, le Sénat, l'Assemblée nationale, les principaux ministères dont le cabinet du chef de gouvernement, la plupart des ambassades, la Cour des comptes, le Conseil constitutionnel). Il arrive même que le centre administratif effectif d'une zone ne se situe PAS sur le territoire de cette zone, mais soit regroupé avec les centres administratifs de plusieurs zones distinctes. Le cas est très courant pour les cantons, gérés par la préfecture ou sous-préfecture quelque part dans le territoire d'une commune "centre" qui parfois n'a aucun territoire dans ce canton); il arrive aussi quand administrativement on sépare une commune centre de tous le reste de sa périphérie dans laquelle la "zone-centre" forme une enclave (ce qui ne veut pas dire non plus que les bâtiments administratifs de la zone-centre soient regroupés au même endroit que ceux de la zone périphérique, ce qui est justement le cas des centres administratifs préfectoraux, ou des conseils généraux et régionaux qui ne pratiquement jamais à la mairie au au centre administratif municipal de la commune chef-lieu) ! Raison de plus pour ne pas référencer systématiquement un lieu très précis (un seul noeud) par le rôle "admin_centre" défini dans la relation de la plupart des grandes zones, mais plutôt une zone délimitée, plus grande que ce noeud (voire plusieurs zones ou noeuds regroupés eux mêmes dans une relation taguée de "type=admin_center" propre à cette collectivité territoriale et pas toujours placés dans le territoire que gère cette collectivité territoriale) : * 1. Comme capitale de la France, le rôle "admin_center" devrait donc désigner la
Re: [OSM-talk-fr] place = locality / hamlet
Le 12/02/2012 13:49, Philippe Verdy a écrit : Le 12 février 2012 13:10, Hélène PETIT a écrit : ...où en est la modif de mapnik qui n'écrit pas le nom de la commune au barycentre de la zone quand il y a un admin-centre dans la relation, merci ? . De plus ce n'est pas l'"admin_centre" qui détermine ça, puisque le nom de l'admin_centre est très souvent différent de celui de la zone définie par la relation, l'admin_centre mentionne le plus souvent le nom de la commune chef-lieu, et ne correspond à la relation QUE quand la relation est une commune (admin_level=8) : il n'y a que dans ce cas-là que les deux noms font alors (éventuellement) doublons. Ben oui, hein, j'avais bien écrit "le nom de la commune" Quand même ... Ya des fois, je me demande. Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Le 12 février 2012 13:10, Hélène PETIT a écrit : > ...où en est la modif de mapnik qui n'écrit pas le nom de la commune au > barycentre de la zone quand il y a un admin-centre dans la relation, merci ? Mapnik ne le fait plus... sauf si la zone est éclatée en plusieurs parties séparées, auquel cas il continue de mettre un label au centre de chacune des sous-zones contigues incluent dans la même relation. De plus ce n'est pas l'"admin_centre" qui détermine ça, puisque le nom de l'admin_centre est très souvent différent de celui de la zone définie par la relation, l'admin_centre mentionne le plus souvent le nom de la commune chef-lieu, et ne correspond à la relation QUE quand la relation est une commune (admin_level=8) : il n'y a que dans ce cas-là que les deux noms font alors (éventuellement) doublons. Enfin la position du chef-lieu ou siège (admin_centre) d'une zone plus grande que la commune n'est franchement pas idéale non plus pour positionner le nom de la zone, pour laquelle Mapnik a raison de placer le label de chaque sous-zone au centre de la zone. Là où je suis moins d'accord, c'est quand Mapnik mentionne le nom de la relation EN MÊME TEMPS avec un label central (ou repositionné avec un rôle 'label" dont les tags de nom n'a aucune importance et est inutile, sachant qu'il n'est alors pas idiot d'avoir plusieurs noeuds membres avec le rôle "label", si une zone contient des exclaves), ET tout le long des frontières. Il devrait pouvoir choisir directement en fonction de l'échelle, selon la place prise par un label central (préférable à faible niveau de zoom quand il est illusoire de vouloir représenter des contours trop petits, le label recouvrant alors une zone plus grande que la zone) par rapport à celle prise par le label affiché sur la frontière (préférable si la représentation de cette frontière est assez longue pour y afficher un libellé). " D'ailleurs le choix des labels multiples qui apparaissent sur les frontière est actuellement complètement stupide, de même que Mapnik ne sait toujours pas placer ces labels du bon côté et insiste pour les mettre tous au milieu de cette frontière, en choisissant parmi eux de façon complètement aléatoire... De même Mapnik ne sait toujours pas dimensionner ou orienter correctement ses labels "centraux": on peut l'aider à le placer avec le rôle "label", mais uniquement sur un noeud "central" et pas le long d'un chemin éventuellement oblique ou courbe. Tous les labels sont alors affichés avec la même taille, horizontalement, sur une largeur "idéale" à priori arbitraire pour couper les mots sur plusieurs lignes. Pour moi, le rôle "label" ne sert qu'à ça : mieux positionner les labels, mais même pas pour désigner le ou les noms à afficher. Ces rôles "labels" devraient être stockés dans la base Mapnik (pas dans la base OSM principale), et y avoir des attributs de taille, couleur, style, et de sélection (ou non) selon le niveau de zoom rendu (un label central apparaitra à un niveau de zoom d'un certain intervalle, mais pas à niveau de zoom trop faible, où rien du tout ne sera affiché, ni à niveau de zoom élevé, où le label central et de position ajustée sera remplacé par des labels de frontières). De ce point de vue-là, Mapquest fait nettement mieux ! La seule motivation pour qu'un "label" (stocké dans la base associée au moteur de rendu) utilise un nom différent des noms de relations OSM, serait qu'un moteur de rendu particulier ait besoin d'une version abrégée des noms stockés dans une relation OSM (avec les tags "name" et "name:*" pour les traductions, "alt_name:*" pour les trouver un noms alternatifs par exemple avec Nominatim, "official_name:*" pour les noms formels rarement représentés sur une carte mais parfois utile au rapprochement de bases de données externes, "old_name:*" pour les anciens noms, etc...), et pour y ajuster la position des sauts de ligne en cas de besoin, voire représenter ces labels sous une forme enrichie par exemple en HTML (sous-éléments en exposants, ou en plus petits caractères...). C'est dans ce cadre là qu'il va vouloir ajuster (et stocker) des préférences de placement, ou vouloir afficher un label le long d'une courbe, ou avec des caractères plus ou moins espacés. Alors je veux bien qu'on ne tague pas pour le rendu, pourtant un moteur de rendu a bel et bien besoin de calculer et conserver ses tags bien à lui pour produire une carte lisible, et permettre d'altérer ce que le placement automatique a mal déterminé : la base OSM ne suffit pas, MÊME avec les meilleurs heuristiques de placement automatique (car il n'existe PAS d'algorithme dès qu'il y a des collisions possibles de labels pour des objets voisins différents ou d'étendues géométriques très différents, ou d'importance relative différente, les critères de sélection et de placements dépendant ce chaque type de rendu de carte et de chaque échelle). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/
Re: [OSM-talk-fr] Retour sur le bogue XML du backend d'Osmose et sur la compatibilité du frontend HTML/JS/CSS
Le 12/02/2012 13:05, Emilie Laffray a écrit : Dans ce cas là, tu contactes les personnes directement. Les points que tu soulèves sont hyper techniques et n'ont pas grand chose à faire sur cette liste. Emilie Laffray Je crois comprendre ce qui se passe : les messages envoyés vers une liste osm en utilisant "Copie à :" semblent rejetés par le robot de liste. Quand Philippe écrit à la liste dev en utilisant un "Pour :", on dirait que ça arrive normalement. à vérifier Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Bien entendu oui. Du coup commencer la discussion sur qui est propriétaire et sur la taille des parcelles dans le cadastre, n'indique pas grand chose pour l'étendue des surfaces "taguées" avec un "landuse". Sauf peut-être concernant les restrictions d'accès (dans les zones militaires par exemple, là où ils sont d'accès interdit, ou bien soumis à un contrôle de d'entrée ou de passage pour les visiteurs du public ou pour les exploitants autorisés des lieux, ces restrictions étant toutefois "taguables" séparément aux points d'entrées et aux barrières, indépendamment du "landuse" qui peut encore être à usage agricole, ou une forêt, même en zone militaire, où il y a pourtant des accès ouverts sous condition en quasi permanence au public, aux heures d'ouverture, comme des chapelles, mémoriaux, cimetières, musées, centres de recrutements et d'évaluation, bureaux d'information, logements des familles...). Le 12 février 2012 12:56, Hélène PETIT a écrit : > Le 12/02/2012 11:25, Philippe Verdy a écrit : > >> Note: des tas de fermiers ne sont pas propriétaires des terrains >> qu'ils exploitent. Le "fermage" est le terme défini pour cette >> location (gratuite ou non) de terrain à usage agricole. > > > oui, bien sur ; mais je ne cartographie pas le type de contrat sous lequel > la terre est utilisée ; seulement "à quoi" il est utilisé ; > "landuse=farmyard" désigne seulement l'utilisation du sol. Idem, quand on > met le tag "landuse=farmland" on ne cherche pas qui est propriétaire du sol. > Tu es d'accord là-dessus ? > > Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Le 12/02/2012 11:59, Vincent Pottier a écrit : Donc en conclusion, vous ne taguez pas pour le rendu.. mais quand même. Et bien c'est typiquement ça : tagguer pour le rendu ! Un nom en l'air qui ne se rapporte à rien d'autre qu'à un segment ! Et c'est quoi ce segment ? Un morceau d'autoroute ? Un mur de centrale nucléaire en construction ? Une ligne haute tension ? Un oued ? Vincent, tu nous fais une panne d'humour là ? Si l'affichage des nom de lieu ne convient pas sur mapnik, c'est mapnik qu'il faut changer, pas la façon d'entrer l'information dans la base. Une fourmi cartographe n'a pas le temps de changer mapnik, à supposer qu'elle sache le faire. La fourmi demande donc à ses copains de changer mapnik ; puis, observant que mapnik se fout intégralement de leur demande (non, non, je ne crois pas que mapnik soit un développeur) les fourmis se mettent à tagguer pour le rendu ; mais comme c'est interdit de tagguer pour le rendu, la fourmi doit à chaque fois préciser "non, non, je ne taggue pas pour le rendu, mais ..." cqfd ...où en est la modif de mapnik qui n'écrit pas le nom de la commune au barycentre de la zone quand il y a un admin-centre dans la relation, merci ? Amicalement, Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Retour sur le bogue XML du backend d'Osmose et sur la compatibilité du frontend HTML/JS/CSS
Dans ce cas là, tu contactes les personnes directement. Les points que tu soulèves sont hyper techniques et n'ont pas grand chose à faire sur cette liste. Emilie Laffray On Feb 12, 2012 10:32 AM, "Philippe Verdy" wrote: > Désolé, mais mes envois à osm-dev-fr ne marchent pas, les emails > reviennent malgré ma tentative de m'y inscrire. > > De même pas moyen de me connecter non plus sur trac.openstreetmap.de > (j'ai bien fait une demande d'inscription, validée par confirmation > d'email, le mot de passe est rejeté, certainement parce que ce serveur > a un certificat de sécurité INVALIDE pour HTTPS, rejeté par le > navigateur, ou bien corrompu et ne contenant pas les bonnes clés de > sécurité pour valider le mot de passe saisi). Une demande de renvoi de > mot de passe ne permet pas non plus de résoudre le problème (j'ai > essayé avec différents navigateurs). Il s'agit d'un bogue > d'installation du serveur web lui-même. > > Le 12 février 2012 09:12, Hélène PETIT a écrit : > > C'est mieux de continuer à utiliser osm_dev-fr > > pour ce sujet là. > > > > Hélène > > > > > > Le 12/02/2012 07:22, Philippe Verdy a écrit : > > > >> === Premier point === > >> > >> Je reviens sur le problème de la fonction quoteattr() du module > >> sax.saxutils actuellement installé sur le serveur Osmose. > > ___ > 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] place = locality / hamlet
Le 12/02/2012 11:25, Philippe Verdy a écrit : Note: des tas de fermiers ne sont pas propriétaires des terrains qu'ils exploitent. Le "fermage" est le terme défini pour cette location (gratuite ou non) de terrain à usage agricole. oui, bien sur ; mais je ne cartographie pas le type de contrat sous lequel la terre est utilisée ; seulement "à quoi" il est utilisé ; "landuse=farmyard" désigne seulement l'utilisation du sol. Idem, quand on met le tag "landuse=farmland" on ne cherche pas qui est propriétaire du sol. Tu es d'accord là-dessus ? Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
> Si ça avait été un point, une surface... ça aurait qualifié un lieu, une > aire... Mais là, avec un segment de droite... ça indique tout sauf le nom > d'un lieu ! Si, si ! une ligne électrique, une route, un chemin, une voie de service, une frontière, un cours d'eau, et sur lequel des logiciels de rendus savent afficher un trait et un nom dessus, à condition de savoir à quoi ça se rapporte. Mais un parc naturel n'est jamais rien de tout ça. En principe un seul point n'indique pas non plus précisément le lieu (il faudrait avoir un rayon indicatif au moins), sinon l'objet désigné est le plus petit polygone contenant le point. De même un seul trait pour une rue, une route ou un cours d'eau n'est acceptable qu'à partir du moment où on peut estimer une largeur minimale indicative (3 mètres maxi par défaut ?), sinon il faut tracer un polygone autour (ce qu'on fait pour les cours d'eau, dont on garde cependant un trait central pour indiquer le centre du cours, ou parce que ce centre virtuel est utilisé aussi comme membre d'une relation de frontière administrative, laquelle devrait aussi être un polygone fermé). === La seule ambiguïté vient des chemins utilisés tout seul et fermés sur eux-mêmes : dans certains cas cela désigne uniquement le chemin lui-même (avec une largeur de part et d'autres si on l'interprète en rue ou cours d'eau), dans d'autre cela désigne la zone contenue dans ce chemin fermé. Normalement il faudrait toujours l'interpréter comme un chemin uniquement, et créer une relation de polygone référençant le chemin comme membre. Mais on évite souvent de créer un multipolygone ne contenant qu'un seul chemin membre, et au lieu de cela on ajoute "area=yes" pour changer l'interprétation par défaut du chemin. Ou alors on indique par exemple type=building dans les tags du chemin, car ce type ne "devrait" (noter le conditionnel...) pas être interprété comme une simple ligne, de sorte que "area=yes" est la valeur "par défaut" (et à priori superflu dans l'état actuel des moteurs de rendus). Pourtant on peut très bien imaginer un objet "building" uniquement linéaire, réduit à un seul mur (mais alors il faut estimer sa largeur par défaut pour le convertir en surface, à priori de l'ordre de 30 cm), ce qui devrait alors nécessiter "area=no" pour ce cas (l'autre solution est de tracer les deux contours fermés intérieur et extérieur de ce mur, et de les mettre dans un multipolygone (qui prend alors la valeur type=building, et non chacun des chemins membres intérieur et extérieur, et dans ce cas pas besoin de "area=no" ni besoin d'estimer une largeur, puisque la surface de ce mur est alors complètement décrite par ce polygone. Tout cela manque de cohérence et de solidité : les chemins ne devraient jamais avoir à être réinterprétés avec une largeur indicative s'ils désignent une surface. Ce devrait être le cas aussi des rues, routes, voies ferrées (qui désignent normalement une surface et pas un simple trait). Mais il y aurait beaucoup de travail pour créer tous leurs contours externes. Mais même dans ce cas, cela ne dispenserait pas de devoir tracer aussi un ou plusieurs chemins intérieurs, pour les différentes voies et sens de circulation ; ainsi que pour le routage qu'on ne sait pas encore faire avec des surfaces (qui de plus ne mentionnent aucune orientation, ce qui reste nécessaire pour définir les restrictions de sens de circulation sur les voies à sens unique). Pour simplifier le problème, on estime "à vue de nez" dans le moteur de rendu une largeur de rue ou de route minimale de l'ordre de 3 mètres, sur une voie à sens unique, ou voisine de 6 mètres pour les voies en double sens, un peu plus s'il y a en plus une voie cyclable et/ou une voie bus de chaque côté, ou un stationnement latéral (pour le faire il faudrait aussi savoir si le stationnement est parallèle à la chaussée ou en épi, savoir s'il y a un trottoir, un terre-plein ou une bordure de séparation avec le trottoir...), encore un peu plus s'il s'agit d'une autoroute à cause de la bande d'arrêt d'urgence et de la barrière centrale... (Cette estimation "à vue de nez" de largeur d'une route est pourtant largeur très allègrement dépassée sans un rendu à un niveau de zoom faible, ou un trait peut couvrir plusieurs centaines de mètres voire des dizaines de kilomètres à l'échelle du pays entier). Si l'estimation "à vue de nez" est loin de la réalité qui est nettement plus large, on "tague" explicitement la largeur moyenne de chaque troncon (incluant toutes ses voies parallèles) si elle est plus large (et on tague aussi le nombre de voies de circulation avec "lanes"). Cependant pour les routes, autoroutes, rocades, ponts, ou tunnels à chaussée, il vaut mieux tracer chaque direction séparément comme des chemins plus ou moins parallèles (qui peuvent s'écarter parfois, au delà d'une simple barrière ou d'un terre-plein centrale de l'ordre du mètre), en les traçant dans chaque sens au centre des voies centrales de circulation générale (ne pas tenir c
Re: [OSM-talk-fr] place = locality / hamlet
Le 12/02/2012 10:31, PhQ a écrit : En région Auvergne, les toponymes cadastraux concernent aussi de nombreuses zones qui sont des lieux-dit stricts, où on ne se pose même pas le problème de savoir s'il y a habitant ou non. Sachant qu'on ne saisie pas pour le rendu mais que sous la référence de base Mapnik (c) les lieux dits apparaissent avec la même graphie que les hameaux (sections de commune) et engendreraient un salmigondis infâme de noms superposés, j'applique la solution suivante : pour rentrer dans la base l'information cadastrale "pré haut" par exemple, je crée un chemin (way) horizontal (ouest - est approché) de dimension identique au texte cadastrale (au niveau 17 18) que je tague name = "Pré Haut", avec la source bien évidemment. Ca apparait sous Mapnik seulement au niveau maximum et ne pollue pas les niveaux inférieurs. Comme je ne suis pas courageux, je n'ai jamais essayé de faire un way horizontal de 20 km de long avec par exemple name= "Parc Régional de ..." histoire de voir ce qui se passerait. (probablement des hurlements et des tas d’erreurs générées - sauf à prévoir un niveau (layer) fictif de 5 ou -5). Donc en conclusion, vous ne taguez pas pour le rendu.. mais quand même. Et bien c'est typiquement ça : tagguer pour le rendu ! Un nom en l'air qui ne se rapporte à rien d'autre qu'à un segment ! Et c'est quoi ce segment ? Un morceau d'autoroute ? Un mur de centrale nucléaire en construction ? Une ligne haute tension ? Un oued ? Si ça avait été un point, une surface... ça aurait qualifié un lieu, une aire... Mais là, avec un segment de droite... ça indique tout sauf le nom d'un lieu ! Aucun logiciel ne peut tirer parti de ça sérieusement. Et j'espère que beaucoup l'éliminent dans la chaîne de traitement. Si l'affichage des nom de lieu ne convient pas sur mapnik, c'est mapnik qu'il faut changer, pas la façon d'entrer l'information dans la base. FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Retour sur le bogue XML du backend d'Osmose et sur la compatibilité du frontend HTML/JS/CSS
Désolé, mais mes envois à osm-dev-fr ne marchent pas, les emails reviennent malgré ma tentative de m'y inscrire. De même pas moyen de me connecter non plus sur trac.openstreetmap.de (j'ai bien fait une demande d'inscription, validée par confirmation d'email, le mot de passe est rejeté, certainement parce que ce serveur a un certificat de sécurité INVALIDE pour HTTPS, rejeté par le navigateur, ou bien corrompu et ne contenant pas les bonnes clés de sécurité pour valider le mot de passe saisi). Une demande de renvoi de mot de passe ne permet pas non plus de résoudre le problème (j'ai essayé avec différents navigateurs). Il s'agit d'un bogue d'installation du serveur web lui-même. Le 12 février 2012 09:12, Hélène PETIT a écrit : > C'est mieux de continuer à utiliser osm_dev-fr > pour ce sujet là. > > Hélène > > > Le 12/02/2012 07:22, Philippe Verdy a écrit : > >> === Premier point === >> >> Je reviens sur le problème de la fonction quoteattr() du module >> sax.saxutils actuellement installé sur le serveur Osmose. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Note: des tas de fermiers ne sont pas propriétaires des terrains qu'ils exploitent. Le "fermage" est le terme défini pour cette location (gratuite ou non) de terrain à usage agricole. Mais cela ne concerne pas que les entreprises agricoles, on trouve du fermage aussi sur des propriétés foncières uniques, mises à disposition d'autres entreprises, qui les louent pour y faire construire leurs bâtiments. Et on ne trouve pas ça qu'en rase campagne ! Ce cas est très fréquent dans les zones périurbaines. Le propriétaire du foncier n'est pas non plus forcément un particulier, ce peut être un syndic de copropriétaires, une entreprise commerciale, un syndicat privé (ou mixte, par exemple à la Défense) d'aménagement, ou une administration publique. Le 12 février 2012 11:15, Philippe Verdy a écrit : > Le 12 février 2012 10:25, Hélène PETIT a écrit : >> J'utilise landuse=farmyard ou landuse=résidential selon le cas. >> >> Dans mon coin il y a beaucoup de petite fermes qui ont été transformées en >> villa lors des regroupement d'exploitations agricole ; il y a eu, la plus >> part du temps, création d'une parcelle de 2000m² au bord d'une route. Il >> faut donc aller y jeter un oeil pour voir si c'est résidentiel ou resté >> agricole ; c'est très interressant à observer, en fait. J'ai trouvé un >> élevage de chevaux de selle, avec espace de dressage, on dirait un club >> hippique, sauf que ce n'est absolument pas ouvert au public ; j'ai mis >> landuse=farmyard. > > Note: des acheteurs investissent dans du terrain pour y faire > construire une propriété, qu'ils aménagent seulement en partie. > > Ce cas arrive dans le cas où l'achat du terrain se fait par lot > indivisible du vendeur ou suite à une adjudication judiciaire. > > La même propriété peut inclure plusieurs parcelles, mais même une > seule parcelle peut être divisée entre une partie résidentielle > (aménagée avec un jardin d'agrément), tandis que le reste est laissé > en pâture pour un fermier du coin, ce qui évite aussi d'avoir à > l'entretenir sur une grande surface (parce que même les terrains > privés doivent être entretenus, par exemple contre le risque > d'incendie qui surviendrait si le propriétaire laissait pousser des > hautes herbes ou proliférer des nuisibles, ou si n'importe en faisait > une décharge sauvage). > > Cette mise à disposition d'une partie du terrain à un fermier, qui en > fait une pâture pour son élevage voire même pour y faire une culture > (ou aussi à une société de chasse, ou une association > environnementale) peut être même totalement gratuite (ou contre un > droit symbolique de fermage) bien que cela reste une propriété privée > (tout le monde n'est pas admis à y entrer sans autorisation du > propriétaire). > > Dans ce cas, on peut avoir différents types de "landuse" pour une même > propriété et même sur la même parcelle (tant que celle-ci n'a pas été > divisée par une revente partielle de ce terrain, l'existence d'une > barrière ou d'une clôture ne signifiant pas nécessairement qu'il > s'agit d'une parcelle différente). > > Noter aussi que le cadastre peut encore contenir des parcelles plus > grandes que la réalité, notamment quand un lotisseur rachète un grand > champ à un agriculteur pour ensuite le viabiliser et le revendre par > lot. Le cadastre enregistrera cette division, posera des nouvelles > bornes pour les constructions à venir et aussi pour le travail de > viabilisation demandé aux communes par le lotisseur avant même que ces > lots soient vendus. > > Mais la mise à jour du cadastre public avec ces subdivisions peut > prendre des mois, même si c'est une opération nécessaire que doit > faire le lotisseur pour revendre les lots à construire (souvent à un > prix très supérieur, le lotisseur faisant un bénéfice très conséquent > sur les travaux de viabilisation obligatoires pour rendre un terrain > constructible et qu'il a préfinancés, ainsi que sur les frais de la > demande de constructibilité des lots demandés par la collectivité > locale). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Le 12 février 2012 10:25, Hélène PETIT a écrit : > J'utilise landuse=farmyard ou landuse=résidential selon le cas. > > Dans mon coin il y a beaucoup de petite fermes qui ont été transformées en > villa lors des regroupement d'exploitations agricole ; il y a eu, la plus > part du temps, création d'une parcelle de 2000m² au bord d'une route. Il > faut donc aller y jeter un oeil pour voir si c'est résidentiel ou resté > agricole ; c'est très interressant à observer, en fait. J'ai trouvé un > élevage de chevaux de selle, avec espace de dressage, on dirait un club > hippique, sauf que ce n'est absolument pas ouvert au public ; j'ai mis > landuse=farmyard. Note: des acheteurs investissent dans du terrain pour y faire construire une propriété, qu'ils aménagent seulement en partie. Ce cas arrive dans le cas où l'achat du terrain se fait par lot indivisible du vendeur ou suite à une adjudication judiciaire. La même propriété peut inclure plusieurs parcelles, mais même une seule parcelle peut être divisée entre une partie résidentielle (aménagée avec un jardin d'agrément), tandis que le reste est laissé en pâture pour un fermier du coin, ce qui évite aussi d'avoir à l'entretenir sur une grande surface (parce que même les terrains privés doivent être entretenus, par exemple contre le risque d'incendie qui surviendrait si le propriétaire laissait pousser des hautes herbes ou proliférer des nuisibles, ou si n'importe en faisait une décharge sauvage). Cette mise à disposition d'une partie du terrain à un fermier, qui en fait une pâture pour son élevage voire même pour y faire une culture (ou aussi à une société de chasse, ou une association environnementale) peut être même totalement gratuite (ou contre un droit symbolique de fermage) bien que cela reste une propriété privée (tout le monde n'est pas admis à y entrer sans autorisation du propriétaire). Dans ce cas, on peut avoir différents types de "landuse" pour une même propriété et même sur la même parcelle (tant que celle-ci n'a pas été divisée par une revente partielle de ce terrain, l'existence d'une barrière ou d'une clôture ne signifiant pas nécessairement qu'il s'agit d'une parcelle différente). Noter aussi que le cadastre peut encore contenir des parcelles plus grandes que la réalité, notamment quand un lotisseur rachète un grand champ à un agriculteur pour ensuite le viabiliser et le revendre par lot. Le cadastre enregistrera cette division, posera des nouvelles bornes pour les constructions à venir et aussi pour le travail de viabilisation demandé aux communes par le lotisseur avant même que ces lots soient vendus. Mais la mise à jour du cadastre public avec ces subdivisions peut prendre des mois, même si c'est une opération nécessaire que doit faire le lotisseur pour revendre les lots à construire (souvent à un prix très supérieur, le lotisseur faisant un bénéfice très conséquent sur les travaux de viabilisation obligatoires pour rendre un terrain constructible et qu'il a préfinancés, ainsi que sur les frais de la demande de constructibilité des lots demandés par la collectivité locale). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Le 11/02/12 18:45, Po G a écrit : Sur le cadastre, un nom est affiché souvent dans les champs à coté des bâtiments d'une ferme. A ma connaissance, ce même nom sert d'adresse. Plusieurs questions : 1 - Utilisez vous "place=locality" ou "place=hamlet" pour une ferme unique ? 2 - Utilisez vous un point ou une area pour enregistrer cette information 3 - Si area : quel contour utilisez vous. Si un point, à quel endroit le placez vous (à la place du texte dans le cadastre ou sur le bâtiment) ? Cdlt POG ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Pour le POI : place=isolated_dwelling : s'il s'agit d'un seul foyer fiscal (peu importe le nombre de bâtiments) place=hamlet : pour 2 foyers fiscaux et plus Pour le détourage de la zone : landuse=farmyard : s'il s'agit d'une ferme, habitation comprise landuse=residential + place=* : pour une zone d'habitation classique. Le place=isolated_dwelling/hamlet/village/town permet de sélectionner le rendu en fonction du niveau de zoom (le rendu officiel ne prend pas encore en compte cette caractéristique mais y en a d'autres qui le font). place=locality : pour désigner un lieu géographique sans nature et sans pourtour définis, indépendamment de toute habitation. Ex : Cap Horn, La Butte aux Cailles (Paris) /Lapi. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] forum: import cadastre village
Le message suivant : ## Bonjour, pouvez vous m'expliquer la procédure pour importer dans osm le cadastre d'un village déterminé svp ? merci. a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2 Une réponse sur la liste directement n'est hélas pas transmise sur le forum, ce qui n'empeche pas une concertation avant réponse par email. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour repondre. -- Tout commentaire sur ce message peut être demandé à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
En région Auvergne, les toponymes cadastraux concernent aussi de nombreuses zones qui sont des lieux-dit stricts, où on ne se pose même pas le problème de savoir s'il y a habitant ou non. Sachant qu'on ne saisie pas pour le rendu mais que sous la référence de base Mapnik (c) les lieux dits apparaissent avec la même graphie que les hameaux (sections de commune) et engendreraient un salmigondis infâme de noms superposés, j'applique la solution suivante : pour rentrer dans la base l'information cadastrale "pré haut" par exemple, je crée un chemin (way) horizontal (ouest - est approché) de dimension identique au texte cadastrale (au niveau 17 18) que je tague name = "Pré Haut", avec la source bien évidemment. Ca apparait sous Mapnik seulement au niveau maximum et ne pollue pas les niveaux inférieurs. Comme je ne suis pas courageux, je n'ai jamais essayé de faire un way horizontal de 20 km de long avec par exemple name= "Parc Régional de ..." histoire de voir ce qui se passerait. (probablement des hurlements et des tas d’erreurs générées - sauf à prévoir un niveau (layer) fictif de 5 ou -5). Donc en conclusion, vous ne taguez pas pour le rendu.. mais quand même. -- View this message in context: http://gis.19327.n5.nabble.com/place-locality-hamlet-tp5475295p5476358.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] place = locality / hamlet
J'utilise landuse=farmyard ou landuse=résidential selon le cas. Dans mon coin il y a beaucoup de petite fermes qui ont été transformées en villa lors des regroupement d'exploitations agricole ; il y a eu, la plus part du temps, création d'une parcelle de 2000m² au bord d'une route. Il faut donc aller y jeter un oeil pour voir si c'est résidentiel ou resté agricole ; c'est très interressant à observer, en fait. J'ai trouvé un élevage de chevaux de selle, avec espace de dressage, on dirait un club hippique, sauf que ce n'est absolument pas ouvert au public ; j'ai mis landuse=farmyard. Pour les agriculteurs qui sont restés, et donc on racheté un gros paquet de terres, ils habitent souvent dans une grosse ferme comportant des bâtiments agricoles et une partie résidentielle avec piscine et parc ; comme c'est tout collé, je mets quand même landuse=farmyard, mais je réfléchis à une alternative. L'utilisation des lieux-dit en tant qu'adresse postale est en désuétude par ici, les communes ont donné des noms de rues à toutes les voies, et la boîte aux lettres associée à un numéro est obligatoire pour recevoir du courrier : il n'y avait de dérogation que pour les très vieilles personnes résidant là depuis longtemps ; mais à présent les communes ont tendance à prendre en charge, dans le cadre de l'aide sociale, la mise en place de la boîte-aux-lettres réglementaire et la relève du courrier . Reste donc le nom de lieu encore en usage, qui recouvre une zone de terrain, habité ou non : là je mets place=locality ; c'est utile quand on randonne à travers champs et collines, parce que les gens qu'on croise les utilisent encore beaucoup. Du coup, je n'utilise jamais locality=hamlet, je mets juste un landuse. Voilà ! Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Retour sur le bogue XML du backend d'Osmose et sur la compatibilité du frontend HTML/JS/CSS
C'est mieux de continuer à utiliser osm_dev-fr pour ce sujet là. Hélène Le 12/02/2012 07:22, Philippe Verdy a écrit : === Premier point === Je reviens sur le problème de la fonction quoteattr() du module sax.saxutils actuellement installé sur le serveur Osmose. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
