Re: [OSM-talk-fr] Faire son plan statique
C'est à dire que faire un rendu statique style Mapnik/OSM à partir
d'un fichier .osm, ça ne va pas marcher?
Si tu regarde bien comment est fait la feuille de stylée de la slippy
map, par exemple pour les barrères:
Style name=barriers
Rule
Filter*(([natural]='hedge') or ([barrier]='hedge'))*/Filter
MaxScaleDenominator12500/MaxScaleDenominator
LineSymbolizer
CssParameter name=strokergb(174,209,160)/CssParameter
CssParameter name=stroke-width3/CssParameter
/LineSymbolizer
/Rule
Et plus loin:
Layer name=line features srs=+proj=merc +a=6378137 +b=6378137
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null
+no_defs +over
StyleNamecliffs/StyleName
StyleName*barriers*/StyleName
Datasource
Parameter name=dbnamegis/Parameter
Parameter name=estimate_extentfalse/Parameter
Parameter name=extent-20037508,-19929239,20037508,19929239/Parameter
Parameter name=hostlocalhost/Parameter
Parameter name=passwordmapnik/Parameter
Parameter name=port5432/Parameter
Parameter name=table
* (select way,barrier,natural,man_made from planet_osm_line where
barrier is not null or natural in ('hedge','cliff') or
man_made='embankment') as roads*
/Parameter
Parameter name=type*postgis*/Parameter
Parameter name=usermapnik/Parameter
/Datasource
/Layer
Mapnik va faire le rendu du calque (layer) line features. Pour celà,
il va sélectionner dans une base de donnée Postgres les élements
concernés grâce à :* (select way,barrier,natural,man_made from
planet_osm_line where barrier is not null or natural in
('hedge','cliff') or man_made='embankment') as roads*.*
*Puis, pour ces éléments, pour ceux qui obeissent au filtre
*(([natural]='hedge') or ([barrier]='hedge'))*, mapnik leur applique le
style barriers et le style cliff déclaré plus haut, à savoir une
ligne de 3 pixels de couleur rgb(174,209,160).
Dans ce cas là, pour utiliser un fichier osm plutot qu'une base de
donnée, celà devrait marcher.
Celà donnerai:
Layer name=line features srs=+proj=merc +a=6378137 +b=6378137
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null
+no_defs +over
StyleNamecliffs/StyleName
StyleName*barriers*/StyleName
Datasource
Parameter name=filemonfichier.osm/Parameter
Parameter name=type*osm*/Parameter
/Datasource
/Layer
Avec une Datasource de type 'osm', tu n'a pas de moyen de sélectionner
des éléments particuliers comme pour une datasource de type 'Postgis'
En revanche, pour le style Power_tower, cela ne marche pas car il n'y a
pas de section Filter dans le style.
Style name=power_towers
Rule
MaxScaleDenominator5/MaxScaleDenominator
PointSymbolizer
file=/home/yves/mapnik/svn2010-09-06/symbols/power_tower.png
type=png width=7 height=7/PointSymbolizer
/Rule
/Style
Celà signifie que quelqu'ils soient, tout les points de ton fichier osm
seront rendu avec la petite croix symbolisant les pylones électriques,
car c'est dans la requete à la base de donner que le filtrage est fait:
(select way from planet_osm_point where power='tower') as power_towers.
Le style s'appliquant à un élément donné est déterminé par la feuille de
style par le fitre filter de la section style ET par la requête à la
base de donnée postgres Parameter name=table.
A moins de tout ré-écrire, pas de solution facile. Mettre en place une
base donnée postgres c'est bien plus facile !
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Place/Boundary (was: Traitement statistiques OSM vs INSEE)
sylvain letuffe sylv...@letuffe.org wrote: Si on parle bien ici du noeud place=hamlet/town/village je m'y oppose farouchement, et je n'hésiterais pas à sortir ma brosse à dent. Je ne parle pas de hamlet, l'insee n'a aucune donnée pour les hameaux. Je ne parle que éventuellement des communes (au sens officiel, cad village, town, city). arf, encore cette éternelle confusion qui me chagrine, je la pensais réglée dans la tête de chacun :-p En tout cas pour moi, commune != place=village/town/city la commune, c'est le truc surfacique avec admin_level=8, une ref:INSEE, un nom et, pourquoi pas, une population. L'exemple classique étant par exemple la commune qui contient plusieurs regroupements de population. En autre terme, une commune contenant deux place=village ne me choque pas du tout, et je n'hésite pas à la faire. D'ailleurs les fusions de communes peuvent donner ce genre de cas. Et, je suis têtu, je cartographie des communes où l'on ne trouve que des hamlet et pas de village. Cela a déjà était évoqué mais rien de tranché. Moi j'ai plutot tendance a mettre la commune en village/town/city, un hamlet n'est pas une commune pour moi, c'est un hameau. Ces différents usages, rendent tout simplement inexploitable les données place ou même boundary pour des usages liés aux communes ou aux populations. Pas grave mais c'est dommage, on dispose de données qui par leur hétérogénéité ne sont pas exploitable. Et ce n'est qu'une vague proposition. Que certains (beaucoup ?) (tous ?) ne fasse pas comme moi, très bien, mais je ne veux pas qu'un robot vienne écraser ma manière de faire. C'est pas du tout le sens de la proposition. La seule chose automatique que j'avais proposé c'était de mettre à jour les populations (suivant la données la plus à jour : le recensement insee) en aucun cas de toucher au tag place... Et effectivement population aurait peut être sa place sur le boundary (avec un admin_centre), mais l'usage actuel c'est tout de même sur place. Avec les précautions habituelles (le wiki n'est pas la loi et chacun tag comme il veut) : Le wiki indique clairement que pour les villes françaises c'est city qu'il faut utiliser et pas hamlet : http://wiki.openstreetmap.org/wiki/FR:Key:place Dans Tracer les limites aucune référence à la population http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limite s_administratives#Communes Mon opinion : Donc clairement l'usage (c'est bien ce que l'on constate en réel) c'est de mettre population sur le node place. La seule source pour les populations en France, c'est l'INSEE, qui répertorie par commune. Coté boundary, je souscrit à 100% au admin_centre. Si ce dernier correspond au node place on y retrouve alors la population et éventuellement d'autres données. Ensuite j'estime que pour les node place il convient de se conformer a la description du wiki, town/city/village pour les communes et hamlet pour les hameaux. Ce n'est pas clair dans les usages et le wiki. Simplement comme je dispose d'un outil pour matché les communes insee/osm et que les données insee (nom et population) sont libre... si c'est vide avant, écraser du vide ne me dérange pas, si c'est un outil qui donne une liste avec conseils, pareil. C'est plutot ma vision des choses. Quand j'aurai avancé un peu plus, je proposerai des listes statistiques. C'est si ça écrase de l'information de manière massive que ça me gêne. Le robot (et son concepteur qui va dernière) ne sait pas pourquoi certaines choses ont été faites, et je préfère alors qu'il s'abstienne. D'autant plus dans le cas de la population où n'importe qui qui ne se satisferait pas de l'information dans osm n'a qu'a reprendre les données de l'INSEE et faire la jointure sur la jolie ref:INSEE qu'on a (presque) mis exprès pour ça Je note pas mal d'erreurs entre ref:INSEE et name tout de même. -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trou dans le cadastre
On 21 nov. 2010, at 01:38, Pierre wrote: Bonjour à tous Alors que je souhaitais compléter OpenStreetMap du côté de Lambersart (à côté de Lille), je fus surpris de n'avoir qu'une surface blanche dans JOSM à un endroit. Après vérification sur le site du cadastre, il s'avère qu'une planche cadastrale manque ! Quel feuille manque exactement ? Tu peux essayer de télécharger toutes les feuilles avec cadget : http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/cadget A première vue, chez moi, pas de problème. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] chemins aménagés pour aveugles
Bonjour à tous, La ville de Fouesnant, Finistère, a aménagé des sentiers avec guide pour aveugles: talus en terre continu ou bordure en bois. Je voudrais savoir s'il est opportun d'ajouter un tag sur le linéaire équipé, et si oui, quel tag. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Place/Boundary
Le 21/11/2010 09:24, Pierre-Alain Dorange a écrit : sylvain letuffesylv...@letuffe.org wrote: Si on parle bien ici du noeud place=hamlet/town/village je m'y oppose farouchement, et je n'hésiterais pas à sortir ma brosse à dent. Je ne parle pas de hamlet, l'insee n'a aucune donnée pour les hameaux. Je ne parle que éventuellement des communes (au sens officiel, cad village, town, city). arf, encore cette éternelle confusion qui me chagrine, je la pensais réglée dans la tête de chacun :-p En tout cas pour moi, commune != place=village/town/city la commune, c'est le truc surfacique avec admin_level=8, une ref:INSEE, un nom et, pourquoi pas, une population. L'exemple classique étant par exemple la commune qui contient plusieurs regroupements de population. En autre terme, une commune contenant deux place=village ne me choque pas du tout, et je n'hésite pas à la faire. D'ailleurs les fusions de communes peuvent donner ce genre de cas. Et, je suis têtu, je cartographie des communes où l'on ne trouve que des hamlet et pas de village. Cela a déjà était évoqué mais rien de tranché. Moi j'ai plutot tendance a mettre la commune en village/town/city, un hamlet n'est pas une commune pour moi, c'est un hameau. Ces différents usages, rendent tout simplement inexploitable les données place ou même boundary pour des usages liés aux communes ou aux populations. Pas grave mais c'est dommage, on dispose de données qui par leur hétérogénéité ne sont pas exploitable. Certaines communes ne sont représentées que par un noeud. Et les informations y sont portées, par défaut. Mais d'autres ont une relation pour la surface : ça représente quand même mieux ce qu'est la commune. Et ce n'est qu'une vague proposition. Que certains (beaucoup ?) (tous ?) ne fasse pas comme moi, très bien, mais je ne veux pas qu'un robot vienne écraser ma manière de faire. C'est pas du tout le sens de la proposition. La seule chose automatique que j'avais proposé c'était de mettre à jour les populations (suivant la données la plus à jour : le recensement insee) en aucun cas de toucher au tag place... Et effectivement population aurait peut être sa place sur le boundary (avec un admin_centre), mais l'usage actuel c'est tout de même sur place. Avec les précautions habituelles (le wiki n'est pas la loi et chacun tag comme il veut) : Le wiki indique clairement que pour les villes françaises c'est city qu'il faut utiliser et pas hamlet : http://wiki.openstreetmap.org/wiki/FR:Key:place Dans Tracer les limites aucune référence à la population http://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_les_limite s_administratives#Communes Mon opinion : Donc clairement l'usage (c'est bien ce que l'on constate en réel) c'est de mettre population sur le node place. La seule source pour les populations en France, c'est l'INSEE, qui répertorie par commune. Le tag population sur les places est là pour des raisons historiques. Mais aujourd'hui on peut faire mieux. La plus part du temps dans un hameau, tu n'as pas besoin d'attendre le passage de l'INSEE pour savoir combien il y a d'habitants ! Coté boundary, je souscrit à 100% au admin_centre. Si ce dernier correspond au node place on y retrouve alors la population et éventuellement d'autres données. Ça ne marche pas dans le cas des communes regroupées, mais aussi dès qu'il y a des habitations éparses et des hameaux. Pourquoi vouloir à tout pris faire coller un node place avec la commune. Un des nombreux exemple que je connais : il y a bien deux village dans la commune, ils on même chacun leur propore sortie de voie rapide. Metre le nom des deux sur l'un seul des deux village n'a pas de sens. http://osm.org/go/b@@bjB0u--?layers=MN Il y a même une commune en France dont le nom du village n'est pas le même que celui de la commune. Il y a aussi des communes sans village ! Ensuite j'estime que pour les node place il convient de se conformer a la description du wiki, town/city/village pour les communes et hamlet pour les hameaux. Ce n'est pas clair dans les usages et le wiki. Simplement comme je dispose d'un outil pour matché les communes insee/osm et que les données insee (nom et population) sont libre... si c'est vide avant, écraser du vide ne me dérange pas, si c'est un outil qui donne une liste avec conseils, pareil. C'est plutot ma vision des choses. Quand j'aurai avancé un peu plus, je proposerai des listes statistiques. C'est si ça écrase de l'information de manière massive que ça me gêne. Le robot (et son concepteur qui va dernière) ne sait pas pourquoi certaines choses ont été faites, et je préfère alors qu'il s'abstienne. D'autant plus dans le cas de la population où n'importe qui qui ne se satisferait pas de l'information dans osm n'a qu'a reprendre les données de l'INSEE et faire la jointure sur la jolie ref:INSEE qu'on a (presque) mis exprès pour ça Je note pas mal d'erreurs entre ref:INSEE et name tout de même. Fred
Re: [OSM-talk-fr] Faire son plan statique
Non, mais, serieux... Je te vois parti avec mapnik, postgres, etc... Bientôt, tu va passer 1 semaine à charger le planet :-( Jette un coup d'oeil à Merkaartor. Tu charge ce que tu veux, le style par défault est proche de Mapnik, print-export to SVG et voilà... - Chris - 2010/11/20 Eric SIBERT courr...@eric.sibert.fr Là, je cherche un tuto spécifique Mapnik et de son plugin permettant de prendre directement un fichier osm. Chez moi, sur Ubuntu cela fonctionne avec: [...] L'installation a réussi. Ensuite, pour l'utiliser, il suffit de la déclarer dans ton fichier de style par exemple: Layer name=routes srs=+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs +over StyleNamemonstyle/StyleName Datasource Parameter name=filemonfichier.osm/Parameter Parameter name=typeosm/Parameter /Datasource /Layer Là, je ne comprends pas ce qu'il faut faire. En revanche: 1) Je ne pense pas que celà soit adapté à de gros fichiers .osm Mon fichier n'est pas gros ;-) 2) 'le rendu mapnik' de www.openstreetmap.org ne fonctionnera pas si vous remplacez simplement les datasource postgis par un appel à votre fichier.osm. C'est à dire que faire un rendu statique style Mapnik/OSM à partir d'un fichier .osm, ça ne va pas marcher? Éric ___ 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/Boundary
Frédéric Rodrigo fred.rodr...@gmail.com wrote: [...] Ces différents usages, rendent tout simplement inexploitable les données place ou même boundary pour des usages liés aux communes ou aux populations. Pas grave mais c'est dommage, on dispose de données qui par leur hétérogénéité ne sont pas exploitable. Certaines communes ne sont représentées que par un noeud. Et les informations y sont portées, par défaut. Mais d'autres ont une relation pour la surface : ça représente quand même mieux ce qu'est la commune. Bien sur, les 2 sont tout le même complémentaire (via admin_centre de la relation). La frontière (surface) représente l'emprise et le noeud place/admin_centre le centre de la commune et une aide potentiel pour représenter le centre réel (par exemple le nom pour le rendu). Actuellement la réalité de OSM et du wiki ne va pas dans ce sens... Il faudrait prévenir quelqu'un sinon personne ne fera comme ça... Sauf peut être ceux qui suivent attentivement cette liste de diffusion. Le wiki FR précise toujours que hamlet ne s'applique pas aux communes par exemple. [...] Mon opinion : Donc clairement l'usage (c'est bien ce que l'on constate en réel) c'est de mettre population sur le node place. La seule source pour les populations en France, c'est l'INSEE, qui répertorie par commune. Le tag population sur les places est là pour des raisons historiques. Mais aujourd'hui on peut faire mieux. La plus part du temps dans un hameau, tu n'as pas besoin d'attendre le passage de l'INSEE pour savoir combien il y a d'habitants ! L'insee ne le dira pas, le comptage unitaire n'est donné qu'au niveau de la commune ; rien au niveau du hameau ou du quartier. La population des hameaux relève de l'évaluation sur le terrain (survey) à priori. Aucune autre info disponible, sauf à consulter les listes électorales (dont l'exploitation dans OSM ne semblerait douteuse au niveau légal). [...] Coté boundary, je souscrit à 100% au admin_centre. Si ce dernier correspond au node place on y retrouve alors la population et éventuellement d'autres données. Ça ne marche pas dans le cas des communes regroupées, mais aussi dès qu'il y a des habitations éparses et des hameaux. Les communes ont toujours un centre administratif (là ou est la mairie au minimum), c'est le rôle de l'admin_centre (centre administratif de la collectivité). Pourquoi vouloir à tout pris faire coller un node place avec la commune. C'est le cas aujourd'hui partout pourtant. De plus comme indiqué plus bas cela à un sens administratif. Cela permet aussi, par exemple, aux logiciels de rendus par exemple d'avoir un endroit précis pour mettre le nom de la commune (sans avoir calculer un barycentre qui peut tomber en plein champ, voir hors commune). Un des nombreux exemple que je connais : il y a bien deux village dans la commune, ils on même chacun leur propore sortie de voie rapide. Metre le nom des deux sur l'un seul des deux village n'a pas de sens. http://osm.org/go/b@@bjB0u--?layers=MN Beychac-et-Caillau à 1942 habitants selon l'INSEE (ref:INSEE 33049). Comme pour toutes les autres communes, l'Insee fournit des données au nveau communal (population, nb résidences...) http://www.recensement.insee.fr/searchResults.action?zoneSearchField=c odeZone=33049-COM Et Beychac-et-Caillau bien que composé de 2 bourgs, ne possède qu'une seule mairie. Au niveau administratif ou il n'y a qu'une seule commune et un seul centre administratif (1 seule mairie). L'insee n'indiquant la population (et les autres statistiques) que de la commune (pas de précision concernant les 2 bourgs). La boundary admin représente une frontière administrative. Chaque collectivité à un seul centre administratif. Après il peut exister plusieurs centres de populations ou d'activités mais c'est un autre domaine. L'INSEE attribu un (seul) code à chaque commune et y associe des données statistiques. Chaque commune n'a qu'un seul centre administratif, même si la commune est composée de plusieurs bourgs. A mon sens, le admin_centre de la relation admin doit pointer sur le centre administratif (d'ou son nom). Après la représentation de 2 bourgs est plus délicate et sujet à interprétation. Mais a ce jour, perso, je me range sur la wiki:fr et donc le met le village centre administratif en place=village (avec les indications qui vont bien) et le second bourg en Hamlet quelque soit sa taille. Il y a même une commune en France dont le nom du village n'est pas le même que celui de la commune. Je ne connais pas ce cas de figure... Il y a aussi des communes sans village ! Oui, l'administration a ces mystères ;-) -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] SUM : Help : Utilisation d'une OrthoPhoto
Hello, Pour conclure ma demande d'aide ( Sujet ci-dessus) . Je peux maintenant m'atteler à la tache devant une image de 25km2 L'image se charge en environ 7 à 9 s les déplacements et zoom sont assez fluide. Voir le résultathttp://merkaartor.be/wiki/merkaartor/Screenshots#Merkaartor-0170-with-GeoTiff-background-and-semi-transparent-map-layer-Mapnik-style Je tiens à remercier Olivier Croquette, Denis Helfer pour leur aide et particulièrement Chris Browet pour le patch sur les plugins Geotiff et Gdal de la version 0.17 de Merkaator pour prendre en compte les spécificités dune image swisstopo level 2. A+ Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Soupçon sérieux de CopyVio ( était Re: Copyvio ? Fwd: Re: [OSM-dev-fr] No uvelles du dépot .osm cadastral cleo)
J'ai eu une réponse de CEDRIC007. Il n'est pas clair dans sa réponse et je ne sais toujours pas s'il viole google ou non. Je lui ai expliqué que le sujet était grave et je lui ai posé la question directement en demandant un oui ou un non. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trou dans le cadastre
Le 21/11/2010 22:19, Pierre a écrit : Plus sérieusement, je ne sais pas qui contacter pour avoir une réponse. Devrais-je contacter la mairie de la ville concernée ? Quand as-tu posé ta question par mail ? Il faut peut-être laisser un peu de délai ? Sinon on trouve ceci dans la FAQ du site du cadastre : Q : La commune recherchée n'est pas disponible, que faire R : La mise en ligne des communes s’effectue de manière progressive. Pour commander des plans cadastraux d’une commune non encore disponible sur cadastre.gouv.fr, veuillez contacter notre service compétent territorialement (retrouvez les coordonnées des centres des impôts fonciers et des centres des impôts en accédant au Menu Contacts de la page d’accueil). Même si ça n'est pas exactement ta question, tu peux tenter le coup. Et pourquoi pas en mairie aussi, en effet. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] chemins aménagés pour aveugles
2010/11/21 Fabrice Phung fabr...@phung.fr La ville de Fouesnant, Finistère, a aménagé des sentiers avec guide pour aveugles: talus en terre continu ou bordure en bois. Je voudrais savoir s'il est opportun d'ajouter un tag sur le linéaire équipé, et si oui, quel tag. Si on veux et je ne sais pas. Mais cela existe peut-être déjà ailleurs. Note qu'il existe une liste de diffusion spécialisée sur ce thème. Voir accessibility (en anglais) sur cette page du wiki : http://wiki.openstreetmap.org/wiki/Contact Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trou dans le cadastre
On 21 nov. 2010, at 21:58, Vincent de Chateau-Thierry wrote: Lambersart est un cadastre vectoriel, donc cadget ne serait pas d'une grande utilité. Je m'insurge :), depuis quelques heures après le message de Pierre, cadget sait aussi récupérer les feuilles-vecteur (sous forme d'image PNG cependant). http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/cadget Ceci dit, la feuille BE manque, ça ne fait pas de doute. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Trou dans le cadastre
2010/11/21 Pierre pina...@pinaraf.info Après vérification sur le site du cadastre, il s'avère qu'une planche cadastrale manque ! Pourrais-tu dire laquelle ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Place/Boundary
2010/11/21 Pierre-Alain Dorange pdora...@mac.com A mon sens, le admin_centre de la relation admin doit pointer sur le centre administratif (d'ou son nom). Après la représentation de 2 bourgs est plus délicate et sujet à interprétation. Mais a ce jour, perso, je me range sur la wiki:fr et donc le met le village centre administratif en place=village (avec les indications qui vont bien) et le second bourg en Hamlet quelque soit sa taille. Euh, c'est marqué comme ça sur le wiki ? Parce que je ne vois pas pourquoi il y aurait des règles différentes entre premier et second bourg. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] syj ne réponds plus ?
Le 22/11/2010 à 10:02:27 +1100 julien balas jul...@krilin.org a écrit Objet: [OSM-talk-fr] syj ne réponds plus ? : http://osm-syj.crans.org/ ne réponds pas chez moi depuis 1 ou 2 jours. C'est moi ou ca fait pareil chez vous ? Je ne peux pas joindre cette adresse non plus. Le site http://downforeveryoneorjustme.com/ confirme la chose aussi. -- Cordialement Hendrik Oesterlin - Nouvelle-Calédonie ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Traitement statistiques OSM vs INSEE
En tout cas pour moi, commune != place=village/town/city la commune, c'est le truc surfacique avec admin_level=8, une ref:INSEE, un nom et, pourquoi pas, une population. +1 : une commune c'est une surface. Point à la ligne. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Place/Boundary (was: Traitement statistiques OSM vs INSEE)
Je note pas mal d'erreurs entre ref:INSEE et name tout de même. Près de chez moi il y a la commune de La Cluse-et-Mijoux. Il n'y a pas de hameau, village ou bourg qui s'appelle La Cluse-et-Mijoux. La mairie se trouve dans le hameau appelé Le Frambourg. Il y a un hameau (plus petit) qui s'appelle la Cluse et un autre Chapelle Mijoux. Pour moi tout ça devrait se tagguer en : - trois points (node) taggués place=hamlet (Le Frambourg, la Cluse, Chapelle Mijoux) - une relation boundary pour les contours de la commune, avec le ref:INSEE, avec comme admin_centre le hameau du Frambourg (qui ne porte donc pas le nom de la commune). La population donnée par l'INSEE n'a de sens que pour cet objet relation donc c'est celui là uniquement qui mériterait (peut-être) de porter la balise population=XXX donnée par l'INSEE. Pour les 3 hameaux on ne peut donner qu'une population approximative qu'aurait indiqué la mairie à un enquêteur OSM zélé, et on ne peut pas donner de ref:INSEE (ou alors, aux trois mais ce n'est alors pas une ref) Damouns ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
