Re: [OSM-talk-fr] Frontière Guyane & changement de licence

2012-03-03 Par sujet Stéphane MARTIN 
Le 03/03/2012 20:37, Stéphane MARTIN a écrit :
> Salut,
> 
> Une bonne âme, pro d'OSM, pourrait-elle se pencher sur les frontières du
> département de la Guyane SVP ?
> 
> Ça pourrait attendre quelques années que je comprenne un peu mieux ;-)
> mais j'ai l'impression que ça touche aussi au très prochain changement
> de licence.
> 
> Voilà le topo :
> 
> - La Guyane, côté Océan, si l'on regarde Mapnik, semble avoir 2
> frontières. L'une au large et l'une sur la côte (déjà signalé sur la
> liste). Même les îles à l'intérieur de la frontière maritime ont aussi
> une ligne frontière sur leurs côtes. Je pensais que c'était normal mais
> j'ai des doutes maintenant.
> 
> - De plus, KeepRight! signale "La frontière de Guyane se sépare ici"
> aussi bien du côté Suriname que du côté Brésil.
> 
> - Enfin, il semble que le contributeur FlorinMateiu n'ait pas accepté la
> nouvelle licence et qu'il soit concerné par quelques unes de ces limites.
> Exemple :
> http://tools.geofabrik.de/osmi/?view=wtfe&lon=-1.80469&lat=35.88371&zoom=2&overlays=overview,wtfe_point_harmless,wtfe_line_harmless,wtfe_point_modified,wtfe_line_modified_cp,wtfe_line_modified,wtfe_point_created,wtfe_line_created_cp,wtfe_line_created
> 
> Bref toutes ces limites me dépassent, si j'ose dire.
> Je veux bien faire quelque chose si l'on me donne une piste mais je ne
> garantis pas de comprendre avant la fin du mois. Ça va sentir le revert...

Le bon lien...

http://tools.geofabrik.de/osmi/?view=wtfe&lon=-51.64417&lat=4.15872&zoom=12&opacity=1.00&overlays=overview,wtfe_point_harmless,wtfe_line_harmless,wtfe_point_modified,wtfe_line_modified_cp,wtfe_line_modified,wtfe_point_created,wtfe_line_created_cp,wtfe_line_created

Sorry !

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Frontière Guyane & changement de licence

2012-03-03 Par sujet Stéphane MARTIN 
Salut,

Une bonne âme, pro d'OSM, pourrait-elle se pencher sur les frontières du
département de la Guyane SVP ?

Ça pourrait attendre quelques années que je comprenne un peu mieux ;-)
mais j'ai l'impression que ça touche aussi au très prochain changement
de licence.

Voilà le topo :

- La Guyane, côté Océan, si l'on regarde Mapnik, semble avoir 2
frontières. L'une au large et l'une sur la côte (déjà signalé sur la
liste). Même les îles à l'intérieur de la frontière maritime ont aussi
une ligne frontière sur leurs côtes. Je pensais que c'était normal mais
j'ai des doutes maintenant.

- De plus, KeepRight! signale "La frontière de Guyane se sépare ici"
aussi bien du côté Suriname que du côté Brésil.

- Enfin, il semble que le contributeur FlorinMateiu n'ait pas accepté la
nouvelle licence et qu'il soit concerné par quelques unes de ces limites.
Exemple :
http://tools.geofabrik.de/osmi/?view=wtfe&lon=-1.80469&lat=35.88371&zoom=2&overlays=overview,wtfe_point_harmless,wtfe_line_harmless,wtfe_point_modified,wtfe_line_modified_cp,wtfe_line_modified,wtfe_point_created,wtfe_line_created_cp,wtfe_line_created

Bref toutes ces limites me dépassent, si j'ose dire.
Je veux bien faire quelque chose si l'on me donne une piste mais je ne
garantis pas de comprendre avant la fin du mois. Ça va sentir le revert...

@+

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées > IRIS & C°

2012-03-03 Par sujet Christian Quest 
Pour ceux qui ne sont pas familiers avec les IRIS de l'INSEE, voici
une page du site de l'INSEE qui explique de quoi il s'agit:
http://www.insee.fr/fr/methodes/default.asp?page=zonages/iris.htm

Il y a environ 16000 IRIS en métropole et 650 dans les DOM. Ils
regroupent en moyenne 2000 habitants.
L'INSEE définit aussi la notion de "grand quartier", qui regroupe
plusieurs IRIS.

Dans ma commune d'un peu plus de 7 habitants, il existe 7
quartiers définis par la commune, chacun étant donc composé en moyenne
de 5 IRIS (en fait de 2 à 9). Toujours dans ma commune, ces
"quartiers" correspondent aux grands quartiers de l'INSEE. Voir:
http://www.insee.fr/fr/methodes/zonages/iris/cartes/carte_iris_94068.pdf

J'ai définit ces 7 quartiers en admin_level=10 pour ne pas confondre
avec l'admin_level=9 des arrondissements municipaux de Paris, Lyon et
Marseille. Pour les quartiers qui ont un "centre" (des commerces
regroupés, un bureau de poste), je pense mettre aussi un admin_centre
mais j'hésite pour le tag place=* entre suburb, neighbourhood et
quarter (en proposition).

J'ai fait de même à Montpellier à partir de leur données en opendata.
Montpellier a aussi la notion de sous-quartiers que j'ai définit en
admin_level=11. A Montpellier, ni les quartiers ni les sous-quartiers
ne correspondent à un découpage de l'INSEE.

Je pense donc plus approprié d'utiliser les admin_level 10 et 11 pour
les découpages décidés par la commune elle même.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
Le 3 mars 2012 23:18, PierreV  a écrit :
>
> verdy_p wrote
>>
>> En gros ce que je voulais dire c'est que ce travail de prémachage des
>> place=* ne sert finalement qu'à Mapnik et son manque de logique
>> justement.
>>
>
> C'est vrai que l'idée de rajouter des niveaux 10,11 voire 12, ne sera qu'une
> variante à la balise "place"
>
> je m'explique,
> jusqu'a présent nous avons pour les niveaux supérieur toujours déterminé un
> "centre" en plus de la surface... le "place" sera le futur "centre" des
> éventuels niveaux 10, 11 voire 12!

Actuellement le centre (rôle "admin_centre") ne suit pas une logique optimale.

Idéalement ce devrait réellement être la désignation du centre
administratif qui devrait donc distinguer l'emplacement de la mairie,
du conseil général, du conseil régional. De plus je me demande à quel
titre il doit être limité à un seul nœud et pas l'ensemble du bâtiment
ou des bâtiments où ces administrations ont leur siège...

Ensuite c'est aux moteurs de rendus de savoir quoi utiliser de ces
éléments géographiques (dont les noms devraient pouvoir être plus
localisés que le nom de la commune, puisque pour le reste c'est
l'adresse de ces objets qui suffit à déterminer le nom de la commune,
si c'est le nom de la commune qu'il est pertinent d'afficher pour un
niveau de zoom donné (qu'on n'a pas à connaitre à priori puisque c'est
chaque moteur qui détermine ce qui est le plus pertinent pour chaque
rendu et chaque niveau de zoom, à condition que la base soit alimentée
de critères objectifs leur permettant de faire ce choix selon ce
qu'ils veulent afficher ou non).

Quand on affiche par exemple une carte à un niveau tel qu'apparait la
commune entière ou une partie de celle-ci, je ne vois pas quel intérêt
à y faire figurer un nœud marqué du nom de la commune, alors qu'on
voudrait y voir "Mairie" ou "Hôtel de Ville", et ailleurs "Conseil
général de Loire-Atlantique" ou "Conseil régional des Pays de la
Loire".

Même pour Paris, désigner un point sur l'Hôtel de ville est trop
restrictif quand on parle de la capitale de la France, qui est en fait
la totalité de la ville. Désigner la ville entière comme
"admin_center" pour la France n'empêchera pas un moteur de rendu de
déterminer un point central s'il y a lieu, ou à un niveau donné de
zoom assez avancé de caler ce point sur une position (à condition
qu'il puisse encore placer l'Hôtel de Ville ou les mairies
d'arrondissements quand on zoome davantage, si c'est plus pertinent
que d'afficher seulement "Paris").

De même rien n'empêche une communauté d'agglomération de placer son
Hôtel d'agglomération, au nom de la communauté et non de la commune où
cet Hôtel d'agglomération est construit. Et alors de désigner ce
bâtiment (ou ensemble contigu de bâtiments) comme "admin_center", sans
nécessité que ce soit limité à un seul nœud (c'est aux moteurs de
rendu de déterminer lequel de la surface ou d'un point unique est le
plus adapté, et il n'est même pas nécessaire non plus pour cet objet
désigné par le rôle "admin_centre" (qu'il soit nœud, "way" fermé, ou
relation de surface) qu'il porte le nom de la relation qui le désigne
(ce nom peut être abrégé à sa seule fonction dans la zone de la
relation qui le désigne). Idem pour les communautés urbaines, ou
communautés de communes ou autres EPCI :

Vouloir placer trop précisément un point comme "admin_centre", c'est
prémâcher le travail en fonction d'un type de moteur, et ça leur
laisse peu de liberté de créer des cartes lisibles puisque cela ne
précise aucune tolérance acceptable de placement des libellés et dans
ce cadre-là il vaut encore mieux ajouter un nœud de rôle "label"
destiné uniquement au placement préférable dans une zone qu'un moteur
pourrait représenter de façon assez détaillée, ce nœud n'étant pas
forcément le mieux si on le place à la mairie, ni non plus quand il
est calculé par un barycentre (ça ne marche pas dans les zones trop
fortement concaves ou ayant des enclaves si ce barycentre calculé
tombe justement dans ces enclaves ou hors de la zone ou pratiquement
sur sa frontière, et il n'y a plus alors moyen algorithmiquement de
déterminer un meilleur point de placement qui tombe dans la zone
effectivement couverte par la relation, surtout s'il y a des
enclaves).

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet PierreV 

verdy_p wrote
> 
> En gros ce que je voulais dire c'est que ce travail de prémachage des
> place=* ne sert finalement qu'à Mapnik et son manque de logique
> justement.
> 

C'est vrai que l'idée de rajouter des niveaux 10,11 voire 12, ne sera qu'une
variante à la balise "place"

je m'explique,
jusqu'a présent nous avons pour les niveaux supérieur toujours déterminé un
"centre" en plus de la surface... le "place" sera le futur "centre" des
éventuels niveaux 10, 11 voire 12!

Voila on avance...
essayons maintenant de comprendre comment adapter "place" pour ne pas avoir
beaucoup de boulot lorsqu'un consensus sera mis en place pour les niveaux
10, 11, et 12?

--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-fusionees-tp5532240p5534464.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] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
En gros ce que je voulais dire c'est que ce travail de prémachage des
place=* ne sert finalement qu'à Mapnik et son manque de logique
justement.

Et que pour le reste on n'en a même pas besoin dans la base, là où des
données de population seraient plus pertinentes, car elles existent
très souvent.

J'en reviens à l'idée de cartographier les IRIS (que l'Insee met en
place progressivement sur tout le territoire (il a fini ce travail
pour toutes les communes de 10 000 habitants et plus, il est en train
de le finir pour celles de plus de 5 000 habitants, et je ne vois pas
pourquoi il s'arrêterait là puisqu'il a bien la notion légale
d'agglomération pour le faire de façon plus poussée et coller mieux à
la législation...) et d'en faire le niveau administratif 10 (sous le
niveau 9 des arrondissements communaux, et le niveau 8 des communes),
pour les alimenter réellement en données de population plus détaillés
(et ne plus utiliser seulement le "pifomètre"), et en laissant de côté
les TRIRIS (destinés surtout aux données économiques).

On attendra pour un niveau 11 (les quartiers ou le premier niveau de
zonage cadastral dans une commune, correspondant en gros à un feuillet
?) ou 12 (les blocs ou "pâtés de maisons", limités par les voies
d'accès, dans lequel figeront sans doûte les hameaux ou "place=hamlet"
et les "isolated_dwelling", ou bien le sous-zonage cadastral
correspondant à une seule feuille détaillée ?).

Le 3 mars 2012 22:27, Hélène PETIT  a écrit :
> Le 03/03/2012 22:04, Vincent Pottier a écrit :
>
>> Peut-être que le premier travail du bot serait de couper le paragraphe
>> en phrases avant de couper les communes en agglomération et les cheveux
>> en quatre.
>
> Yacc !
> http://en.wikipedia.org/wiki/Yacc
>
>
> ___
> 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] ITO maps

2012-03-03 Par sujet Hélène PETIT 

Le 03/03/2012 14:01, Ab_fab a écrit :

Une nouvelle moûture des cartes thématiques ITO est arrivée, avec de
nouveaux thèmes

superbe ! merci pour l'info ;
je me sers beaucoup de ito pour comprendre ce que font les autres 
contributeurs de mon coin.


:>)))


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Hélène PETIT 

Le 03/03/2012 22:04, Vincent Pottier a écrit :

Peut-être que le premier travail du bot serait de couper le paragraphe
en phrases avant de couper les communes en agglomération et les cheveux
en quatre.

Yacc !
http://en.wikipedia.org/wiki/Yacc

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Hélène PETIT 

Le 03/03/2012 19:40, sly (sylvain letuffe) a écrit :

Voici mon tableau d'échelle :
http://wiki.openstreetmap.org/wiki/Proposed_features/world_wide_place_default_standardisation


Merci pour ce tableau qui a l’avantage d'être clair ; je me demande 
quel peut être l'équivalent de "households" dans les régions où les gens 
vivent en groupes différents selon le jour/la nuit/le sexte/le mois et 
où les abris ne servent pas à héberger une famille, mais plutôt une 
activité communautaire ; en fait il n'y a là-bas que des "amenities", 
pas de "foyers" au sens occidental du terme.


Je préfère cartographier les batiments (buiding=yes) et l'usage qui en 
est fait (landuse=residential ; landuse=farmyard ; etc) le rendu est 
parfais sous mapnick, qui est pour l'instant notre vitrine de démo en 
première intention (restons factuels) ?


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Vincent Pottier 

Le 03/03/2012 21:47, Hélène PETIT a écrit :


** y-a-t'il, ou n'y a-t-il pas, d'habitants dans le périmètre (vague) 
défini par un lieu-dit (place=locality) ? le lieu-dit français ne 
"colle pas", sémantiquement parlant, avec le lieu-dit traduit de 
l'anglais ; nerfs-solides=utiles, HURLEMENTS=néfastes.
C'est toue la question du "lieu", un lieu, ça n'est pas un périmètre 
mais c'est un concept qui est à peu près par-là...

--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Vincent Pottier 

Le 03/03/2012 21:51, Hélène PETIT a écrit :

Le 03/03/2012 20:35, Philippe Verdy a écrit :

De quoi vérifier les communes (celles qui ont un découpage zonal, à
commencer par celles entre 5 000 et 10 000 qui ont ce découpage zonal)
qu'on a classées comme "place=village" alors que ça prend en compte
toute la population communale et non l'agglomération qu'on veut faire
figurer sur la carte pour la séparer de ses hameaux que les
préfectures ont converties en agglomération au sens du code de la
route et non celui défini par l'Insee.


Ce que tu décris-là est un algorithme ; du boulot pour un bot, pas un 
boulot pour moi-miaou.
J'espère que le bot comprendra mieux le paragraphe que moi, mais j'ai 
des doutes :-)
Peut-être que le premier travail du bot serait de couper le paragraphe 
en phrases avant de couper les communes en agglomération et les cheveux 
en quatre.

--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Hélène PETIT 

Le 03/03/2012 20:35, Philippe Verdy a écrit :

De quoi vérifier les communes (celles qui ont un découpage zonal, à
commencer par celles entre 5 000 et 10 000 qui ont ce découpage zonal)
qu'on a classées comme "place=village" alors que ça prend en compte
toute la population communale et non l'agglomération qu'on veut faire
figurer sur la carte pour la séparer de ses hameaux que les
préfectures ont converties en agglomération au sens du code de la
route et non celui défini par l'Insee.


Ce que tu décris-là est un algorithme ; du boulot pour un bot, pas un 
boulot pour moi-miaou.





___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Hélène PETIT 

Le 03/03/2012 19:30, PierreV a écrit :

heu... comment traduit-on dans osm:
ville
village
ecart
hameau
lieu dit


Rien que pour le lieu-dit**, les historiques du wiki (version anglophone 
 ET version francophone) sont très révélateurs des difficultés à 
établir un consensus entre contributeurs ; ça vaut la peine de lire 
tout, tout en se disant que, c'est sûr, un jour, on y arrivera (au 
concensus) ; l'entropie, ça existe, ça fait partie des sciences dures, 
j'y crois dur comme fer.


Tout en restant un schtroupf-noir, d'ailleurs.


** y-a-t'il, ou n'y a-t-il pas, d'habitants dans le périmètre (vague) 
défini par un lieu-dit (place=locality) ? le lieu-dit français ne "colle 
pas", sémantiquement parlant, avec le lieu-dit traduit de l'anglais ; 
nerfs-solides=utiles, HURLEMENTS=néfastes.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
J'en reviens tout de même aux IRIS: quand ils existent, c'est un bon
moyen de savoir (en regardant leur délimitations) la population
concernée d'un village, pour savoir si l'agglomération désignée comme
"centre" mérite son statut de "place=village" ou pas. C'est objectif
et pas établi au pifomètre.

De quoi vérifier les communes (celles qui ont un découpage zonal, à
commencer par celles entre 5 000 et 10 000 qui ont ce découpage zonal)
qu'on a classées comme "place=village" alors que ça prend en compte
toute la population communale et non l'agglomération qu'on veut faire
figurer sur la carte pour la séparer de ses hameaux que les
préfectures ont converties en agglomération au sens du code de la
route et non celui défini par l'Insee.

Pour ces hameaux devenus pseudo-agglomérations, il sera utile (et même
indispensable) de "taguer" explicitement la limitation de vitesse
applicable, de même pour les villages centres dont la population dans
son agglomération (comptée en totalisant uniquement les IRIS
concernés) n'attend pas les seuils suffisants (je pense que les
communes de 5 000 à 10 000 habitants qui ont un découpage zonal IRIS
pourraient toutes être des "place=village" au minimum malgré tout sans
tenir compte du statut ou non d'agglomération pour le village centre
ou de la population qui y réside (selon les IRIS).

Pour les autres communes, il ne reste que l'interprétation "au pif"
selon les bâtiments qu'on compte autour du point désigné comme central
(on pourrait retenir malgré tout pour ce comptage le critère de
proximité utilisé par l'Insee pour définir les agglomérations).

Dans les deux cas (pour le deuxième à condition que le bâti ait été
importé du cadastre), c'est quelque chose de vérifiable qu'un robot
peut faire, même s'il y a des imperfections nombreuses dans les
données du bâti (comptage des zones fermées définissant les bâtiments
dans un périmètre restreint de recherche autour des bâtiments en
commençant par le point désigné par un tag "place=*").

Le 3 mars 2012 20:15, Vincent Pottier  a écrit :
> Le 03/03/2012 19:50, Philippe Verdy a écrit :
>>
>> C'est bien ce que je disais... Critère non objectif pour la plupart des
>> "place".
>>
>> Qui ne seront à garder que lorsqu'on n'a pas de données statistiques
>> vérifiables ni aucun statut de chef-lieu de quelquechose.
>>
>> Il me semble toute de même que pour obtenir le statut d'agglomération,
>> l'Insee (et les préfets qui prennent les arrêtés pour la signalisation
>> routière) ont besoin d'avoir des chiffres de population fiables.
>
> Je suis persuadé que le critère de population intervient, mais pas que...
> Je me demande si ça ne correspond pas aussi à des demandes des communes pour
> des questions d'entretien de voirie ou des abords...
> Et les préfets (et leurs techniciens) utilisent aussi leur intelligence qui
> croisent des données quantifiables et d'autres non quantifiable : densité,
> dangerosité...
>
> Dans un village, la route fait un long virage avant l'entrée avec un gros
> talus à l'intérieur du virage. Pas de visibilité. Le panneau d’agglomération
> a été placé avant le virage, un moyen facile de faire tomber la vitesse.
>
>>
>> Le 3 mars 2012 19:40, sly (sylvain letuffe)  a écrit :
>>>
>>> Le samedi 3 mars 2012 18:33:19, PierreV a écrit :
>>>
 je n'ai pas de réponse concrète sur le moyen de tager correctement mes
 différents "place" au sein meme d'une seule commune...
>>>
>>> J'utilise le "pif" pour estimer la population et je choisi mon "place"
>>> uniquement sur la base de cette estimation (je ne rentre que rarement le
>>> tag
>>> population, justement car je ne l'ai pas)
>
> +1, Un pifomètre bien calibré est un excellent instrument de mesure !
> Et plus on l'utilise (de façon intelligente et en regardant ce qui se fait
> ailleurs) plus il s'affine.
> --
> FrViPofm
>
>
> ___
> 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] Communes fusionées

2012-03-03 Par sujet Vincent Pottier 

Le 03/03/2012 19:50, Philippe Verdy a écrit :

C'est bien ce que je disais... Critère non objectif pour la plupart des "place".

Qui ne seront à garder que lorsqu'on n'a pas de données statistiques
vérifiables ni aucun statut de chef-lieu de quelquechose.

Il me semble toute de même que pour obtenir le statut d'agglomération,
l'Insee (et les préfets qui prennent les arrêtés pour la signalisation
routière) ont besoin d'avoir des chiffres de population fiables.

Je suis persuadé que le critère de population intervient, mais pas que...
Je me demande si ça ne correspond pas aussi à des demandes des communes 
pour des questions d'entretien de voirie ou des abords...
Et les préfets (et leurs techniciens) utilisent aussi leur intelligence 
qui croisent des données quantifiables et d'autres non quantifiable : 
densité, dangerosité...


Dans un village, la route fait un long virage avant l'entrée avec un 
gros talus à l'intérieur du virage. Pas de visibilité. Le panneau 
d’agglomération a été placé avant le virage, un moyen facile de faire 
tomber la vitesse.


Le 3 mars 2012 19:40, sly (sylvain letuffe)  a écrit :

Le samedi 3 mars 2012 18:33:19, PierreV a écrit :


je n'ai pas de réponse concrète sur le moyen de tager correctement mes
différents "place" au sein meme d'une seule commune...

J'utilise le "pif" pour estimer la population et je choisi mon "place"
uniquement sur la base de cette estimation (je ne rentre que rarement le tag
population, justement car je ne l'ai pas)

+1, Un pifomètre bien calibré est un excellent instrument de mesure !
Et plus on l'utilise (de façon intelligente et en regardant ce qui se 
fait ailleurs) plus il s'affine.

--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
C'est bien ce que je disais... Critère non objectif pour la plupart des "place".

Qui ne seront à garder que lorsqu'on n'a pas de données statistiques
vérifiables ni aucun statut de chef-lieu de quelquechose.

En pratique cela veut dire que tout ce qui est "taggué" comme
"place=village ou "place=hamlet" est souvent très discutable entre les
deux statuts donnés (surtout s'il n'y a pas de délimitation de
frontière associée et vérifiable par une source, ne serait-ce que la
définition Insee des agglomérations qui me ferait alors préférer très
nettement "place=village", donc effectivement par la présence d'un
panneau d'entrée dans une agglomération même si ce n'est pas la
commune centre qui elle aussi pourra être de type "village" bien
qu'incluant aussi cette agglomération secondaire dans ses frontières).

Il me semble toute de même que pour obtenir le statut d'agglomération,
l'Insee (et les préfets qui prennent les arrêtés pour la signalisation
routière) ont besoin d'avoir des chiffres de population fiables. Ces
chiffres doivent exister quelque part avec une source vérifiable (si
ce n'est pas l'Insee qui a ces chiffres, ce peut être l'administration
fiscale qui établit une estimation, voire un organisme social
paritaire).

Le 3 mars 2012 19:40, sly (sylvain letuffe)  a écrit :
> Le samedi 3 mars 2012 18:33:19, PierreV a écrit :
>
>> je n'ai pas de réponse concrète sur le moyen de tager correctement mes
>> différents "place" au sein meme d'une seule commune...
>
> J'utilise le "pif" pour estimer la population et je choisi mon "place"
> uniquement sur la base de cette estimation (je ne rentre que rarement le tag
> population, justement car je ne l'ai pas)
>
> Voici mon tableau d'échelle :
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/world_wide_place_default_standardisation

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] forum: fichier marqueurs.txt

2012-03-03 Par sujet forum 
Le message suivant :
##
Bonjour,

j'ai suivi cet exemple pour afficher une carte avec des données enregistrées 
dans un fichier txt. 
Exemple ici 
[url]http://wiki.openstreetmap.org/wiki/FR:Openlayers_POI_layer_example[/url]
Je me demandais s'il est possible d'intégrer des liens vers une autre page du 
site à la place par exemple de la colonne description ? 

Par avance merci

Loic

a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=3
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] Communes fusionées

2012-03-03 Par sujet sly (sylvain letuffe) 
Le samedi 3 mars 2012 18:33:19, PierreV a écrit :

> je n'ai pas de réponse concrète sur le moyen de tager correctement mes
> différents "place" au sein meme d'une seule commune...

J'utilise le "pif" pour estimer la population et je choisi mon "place" 
uniquement sur la base de cette estimation (je ne rentre que rarement le tag 
population, justement car je ne l'ai pas)

Voici mon tableau d'échelle :

http://wiki.openstreetmap.org/wiki/Proposed_features/world_wide_place_default_standardisation

-- 
sly (sylvain letuffe)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet PierreV 

verdy_p wrote
> 
> Justement j'y ai répondu, les différents place sont finalement peu
> pertinents et établis pour un moteur de rendu spécifique 
> ...
> 


heu... comment traduit-on dans osm:
ville
village
ecart
hameau
lieu dit
...

et a mon avis le tag "place" est la pour ca?


--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-fusionees-tp5532240p5534125.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] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
Justement j'y ai répondu, les différents place sont finalement peu
pertinents et établis pour un moteur de rendu spécifique (Mapnik, même
si Osmarender, alias Tiles@home, en tient compte encore, mais va sans
doûte s'arrêter). Avec des critères de seuils de population
arbitraires (en principe uniques, mais avec de nombreuses exceptions).

Quand je parlais des IRIS c'était pour dire que des chiffres de
population existent bel et bien à des échelles infracommunales (ce qui
devrait aussi te guider pour savoir quel "place" utiliser, même si
évidemment cela ne peut pas répondre aux cas des communes de moins de
5000 habitants, dont bon nombre comportent plusieurs petites
agglomérations, qu'on repère avec les panneaux faute de mieux, et de
sources Insee capable de compter les habitants à ce niveau).

Le fait que j'habite une "grande" ville ou pas (pas si grande que ça
en fait) ne change rien à ma réponse, et j'ai aussi habité des petites
communes (de 2000 habitants environ ou moins), dont une était divisée
en plusieurs villages (en fait des communes associées) sur deux
agglomérations distinctes.

Le 3 mars 2012 19:14, PierreV  a écrit :
> tu sais faire autre chose qu'une dissertation en répondant à coté du "vrai
> problème"?
> Le fait que les IRIS concernent aussi les communes de 5 000 et 10 000
> habitants ne change absolument rien au problème de comment tager les
> différents "place="
>
> je suis désolé pour toi si tu habite dans une "grande ville", mais sur la
> surface de la france les communes de moins de 5 000 habitant sont a mon avis
> en très grande majorité... quand on compare leur "surface"
>
> c'est bien dommage de vouloir s'obstiner à vouloir avoir les "grandes
> villes" hyper précises si dans les communes voisines meme les routes
> secondaires ne sont pas renseignées.
>
> c'est dans ce but de vouloir proposer une france "remplie uniformément"
> quelque soit le territoire que j'essaye de savoir comment correctement tager
> les "place=..." en sachant qu'en france nous n'avons pas le détail des
> populations.
>
> A mon avis ce débat a du déja etre dans les autres pays, et a mon avis ce
> n'est pas pour rien qu'ils ont choisi le critère de la population...
>
> Donc si le critère du rendu pour mapnik a été choisi, a nous d'etre assez
> inteligent pour choisir un critère logique!
>
> Vous dites que le nombre d'habitants n'est que trop subjectif, moi je
> propose l'utilisation des panneaux routiers d'entrée de villes et villages:
> - Panneau Blanc entouré de rouge: "Place=village" (ou supérieur)
> http://g.co/maps/zsdcb
> - Panneau Blanc entouré de rouge AVEC deuxieme ligne "commune de...":
> "place=hamlet" http://g.co/maps/cbu8e
> - Panneau Noir écriture blanc: "place=isolated_dwelling"
> http://g.co/maps/yujqp
>
> voila qu'est ce que vous en pensez?
>
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Communes-fusionees-tp5532240p5534088.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

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet PierreV 
tu sais faire autre chose qu'une dissertation en répondant à coté du "vrai
problème"?
Le fait que les IRIS concernent aussi les communes de 5 000 et 10 000
habitants ne change absolument rien au problème de comment tager les
différents "place="

je suis désolé pour toi si tu habite dans une "grande ville", mais sur la
surface de la france les communes de moins de 5 000 habitant sont a mon avis
en très grande majorité... quand on compare leur "surface"

c'est bien dommage de vouloir s'obstiner à vouloir avoir les "grandes
villes" hyper précises si dans les communes voisines meme les routes
secondaires ne sont pas renseignées.

c'est dans ce but de vouloir proposer une france "remplie uniformément"
quelque soit le territoire que j'essaye de savoir comment correctement tager
les "place=..." en sachant qu'en france nous n'avons pas le détail des
populations.

A mon avis ce débat a du déja etre dans les autres pays, et a mon avis ce
n'est pas pour rien qu'ils ont choisi le critère de la population... 

Donc si le critère du rendu pour mapnik a été choisi, a nous d'etre assez
inteligent pour choisir un critère logique!

Vous dites que le nombre d'habitants n'est que trop subjectif, moi je
propose l'utilisation des panneaux routiers d'entrée de villes et villages:
- Panneau Blanc entouré de rouge: "Place=village" (ou supérieur)
http://g.co/maps/zsdcb
- Panneau Blanc entouré de rouge AVEC deuxieme ligne "commune de...":
"place=hamlet" http://g.co/maps/cbu8e
- Panneau Noir écriture blanc: "place=isolated_dwelling"
http://g.co/maps/yujqp

voila qu'est ce que vous en pensez?

--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-fusionees-tp5532240p5534088.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] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
Le 3 mars 2012 18:58, PierreV  a écrit :
> je croyais que l'on mappais pas pour un rendu... ;-) donc fausse réponse
> qu'est celle de l'interprétation des moteurs de rendu ;-)

Justement c'est très pertinent, car les "place" ont clairement été
définis en fonction d'un critère retenu pour un moteur de rendu
spécifique (Mapnik) qui ne sait pas utiliser des critères plus
objectifs !

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
Le 3 mars 2012 18:48, PierreV  a écrit :
> ah... j'avais pas remarqué que les IRIS ne concernent uniquement les villes
> de plus de 10 000 habitants...

Non cela concerne aussi la plupart des communes de plus de 5 000
maintenant (ce nombre va croissant, et il est probable que cela se
généralise bientôt à toutes les communes de plus de 5 000 habitants).

Pour nombre de communes de 5 000 à 10 000 habitants, on parle encore
assez souvent de villages, et cela concerne une bonne partie des
communes ayant fusionné ou s'étant associées.

D'autre part les communes "associées" sont en diminution constante.
Leur création vient du temps où n'existait pas encore les communautés
de communes, afin qu'elles regroupent certaines compétences (aussi
pour augmenter les garanties financières lorsqu'elles dont appel au
crédit).

Aujourd'hui la plupart des banques demandent des garanties
financières, et ne se contentent plus non plus de la certification des
comptes des collectivités publiques (par un commissaire au compte, et
sous le contrôle de de la Cour des comptes), mais demandent que les
collectivités fassent évaluer leurs comptes par une agence de notation
qui les publiera (Moody's, Standard & Poor's, Fitch Ratings...). Ce
sont alors ces collectivités qui sont les clientes de ces agences et
payent pour ces notations financières (ces agences ont pris clairement
le pouvoir sur la Cour des comptes, suite aux exigences des banques
qui accordent les crédits). Pas étonnant non plus que pratiquement
toutes les communes maintenant soient obligées d'adhérer à une
communauté de communes (et depuis peu, l'Etat les y oblige
pratiquement pour des raisons de gestion et redistribution des
recettes fiscales).

De fait, comme la plupart des compétences non gérées localement par
les communes associées ont été transférées de la commune à la
collectivité de communes, quand il ne reste plus de compétence
particulière pour la commune dans sa globalité, soit les communes
fusionnent directement, soit elles se séparent et redeviennent des
communes à part entière au sein d'une communauté de communes (et
parfois les communes associées qui se séparent optent d'aller vers une
communauté de communes voisine).

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet PierreV 
je croyais que l'on mappais pas pour un rendu... ;-) donc fausse réponse
qu'est celle de l'interprétation des moteurs de rendu ;-)

Donc je propose une solution qui permet d'avoir un avis objectif, en
utilisant la "classification" des panneaux routiers puisque vous avouez que
la classification par habitants n'est pas réalisable:
- Panneau Blanc entouré de rouge: "Place=village" (ou supérieur)
http://g.co/maps/zsdcb
- Panneau Blanc entouré de rouge AVEC deuxieme ligne "commune de...":
"place=hamlet" http://g.co/maps/cbu8e
- Panneau Noir écriture blanc: "place=isolated_dwelling"
http://g.co/maps/yujqp


je sais je suis tétu... mais faut bien un jour qu'on trouve un compromis...
et je suis sur que c'est réalisable avec les membres de cette ML...

C'est bien domage d'essayer d'éviter le "débat" et de ne pas trouver un
compromis qui convienne a tout le monde et ainsi de pouvoir proposer une
unité sur l'ensemble de la france!

--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-fusionees-tp5532240p5534039.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] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
A mon avis la classification des "place" est finalement peu pertinente
car pas objective. Elle souffre trop les interprétations (et se fait
selon ce qui est voulu pour certains moteurs de rendu spécifiques).
Les critères adoptés à priori sont mal vérifiés.

Il semble bien que Mapquest n'en tienne pas compte du tout ! et qu'il
s'en tient aux chiffres de population (je ne sais pas s'il utilise
ceux renseignés par la base OSM ou s'il n'a pas sa propre copie des
données Insee), où à ses propres critères de classification (tenant
compte des statuts de chef-lieu).

Le 3 mars 2012 18:33, PierreV  a écrit :
> alors meme si se devrait etre des "robots" qui doivent importer les données
> de population au sein meme d'une commune en fonction de ses différents
> villages, où est-ce que l'on peut consulter cette donnée pour pouvoir ainisi
> taguer correctement les villages aux alentours d'une commune en fonction de
> la population comme le conseille OSM?
>
> car vous vous embarquez encore une fois dans des débats intéressants, mais
> je n'ai pas de réponse concrète sur le moyen de tager correctement mes
> différents "place" au sein meme d'une seule commune...
>
> merci d'avance de votre réponse

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet PierreV 
ah... j'avais pas remarqué que les IRIS ne concernent uniquement les villes
de plus de 10 000 habitants...

donc comment on fait pour déterminer la population des communes entre 1 000
et 10 000 habitants si elles sont composées de plusieurs villages? et donc
de leur déterminer le "place" adéquat?

La solution des IRIS est une "fausse" réponse... et est un autre débat..

--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-fusionees-tp5532240p5534015.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] Communes fusionées

2012-03-03 Par sujet PierreV 
alors meme si se devrait etre des "robots" qui doivent importer les données
de population au sein meme d'une commune en fonction de ses différents
villages, où est-ce que l'on peut consulter cette donnée pour pouvoir ainisi
taguer correctement les villages aux alentours d'une commune en fonction de
la population comme le conseille OSM?

car vous vous embarquez encore une fois dans des débats intéressants, mais
je n'ai pas de réponse concrète sur le moyen de tager correctement mes
différents "place" au sein meme d'une seule commune...

merci d'avance de votre réponse

--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-fusionees-tp5532240p5533996.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] Foursquare passe a OSM

2012-03-03 Par sujet Philippe Verdy 
Il y a encore d'autres fournisseurs pour les orthophotos.

En adoptant OSM, ils peuvent aussi vouloir utiliser la concurrence et
voir si Bing n'est pas moins cher que Google pour eux (et il me semble
que pour l'instant Bing, allié à Yahoo! qui a abandonné ce service,
reste tenté de ne pas facturer son service, pour contrebalancer le
pouvoir trop monopolistique acquis par Google)...

Pour d'autres zones ou pays, il y a aussi des services d'orthophoto
fournis gratuitement par les institutions publiques.

Donc à ces services d'utiliser la concurrence. Google n'est pas le
seul vendeur !

Le 1 mars 2012 10:48, Ab_fab  a écrit :
> Merci pour l'info !
>
> La perte des orthophotos est également un motif d'insatisfaction récurrent
> dans le cas de 4square.
> OSM n'y peut pas grand chose.
>
> Le 1 mars 2012 10:31, Club Informatique Inter Communes / C2IC
>  a écrit :
>
>> Bonjour,
>>
>> > A ce propos, est-ce que les adeptes du geocaching ont pu déceler des
>> > discussions liées à la contribution OSM sur des forums ou autres ?
>>
>> Il y a eu une petit discussion sur un forum de géocacheurs français
>> (http://france-geocaching.fr) où le soucis le plus important semblait
>> être la disparition de la vue aérienne dans les différentes couches de
>> cartes proposées. J'y ai fait une annonce pour proposer aux
>> géocacheurs de devenir contributeurs OSM mais il n'y a pas eu de
>> réactions sur ce sujet précisément.
>>
>> Je ne suis pas convaincu que les géocacheurs se penchent sur la
>> nécessité de mettre à jour la carte OSM ! Du moins sur les forums
>> c'est plus la possibilité de retrouver la carte "google" qui fait
>> parler et réagir plutôt que la contribution à OSM.
>>
>> Lionel / C2iC
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> --
> ab_fab
> "Il n'y a pas de pas perdus"
>
> ___
> 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] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
Pourquoi ne pas les mettre ? On a les tags "population=*" et
"population:year=*" pour assurer le suivi des données et
"source:population=INSEE" quand la source (toujours datée) est
l'Insee, la seule source valable en France.

Un robot n'a qu'à les mettre à jour, et ces chiffres permettent
d'adapter le rendu (par exemple pour sélectionner automatiquement les
libellés à conserver quand on ne peut pas les faire tenir tous sans
superposition). Ainsi, pas besoin même de la classification des
"places" (qui n'est finalement pas très homogène).

Un moteur de rendu pourra choisir les libellés à retenir (et les
tailles de polices ou de symboles à utiliser), selon deux critères
réellement objectifs : la population, et le statut d'une commune comme
chef-lieu (rôle "admin_centre") d'un niveau administratif, selon ses
besoins qu'on n'a pas à décider dans OSM.

Le seul soucis est que souvent la population a été mise sur le nœud
définissant le centre administratif d'une commune, alors que cela n'a
aucun sens à ce niveau-là, et que ce chiffre de population (comme
aussi le numéro de référence Insee) devrait être attribué à la
relation définissant les frontières.

De même le nom (officiel, éventuellement traduit) d'une commune est en
priorité celui de la relation (et non celui du nœud de type "place=*"
indiqué par le role "admin_centre" qui peut n'être qu'un nom local
correspondant à une entité plus petite que la commune). Si une carte
ne peut pas représenter les frontières d'une communes mais ne peut
afficher qu'un nœud, il ignorera aussi la position exacte du centre
administratif, mais l'utilisera quand même pour positionner le nom de
la commune (si la précision est suffisante pour que cela fasse une
différence dans l'affichage, sinon il suffira d'ignorer aussi la
position de cet "admin_centre" pour ne garder qu'un centroïde
calculé), et le nom à afficher devrait être celui de la relation de
commune (et non celui du centre administratif), car c'est le seul nom
pertinent à l'échelle de zones plus grandes comme les départements ou
régions. Ce sont les données de la relation qui seront utilisées
alors.

Là encore ce n'est pas à OSM de décider les données que
sélectionneront les moteurs de rendus, mais il faut être cohérent dans
ce qui est réellement désigné : donc toutes les communes doivent avoir
un nom officiel dans la relation, même si le nœud désigné par
"admin_centre" peut avoir un nom différent plus local (qui pourrait
même être réduit à "Mairie" ou "Hôtel de Ville" seulement), et leur
population mentionnée dans la relation (et non l’objet désigné par le
rôle "admin_centre" de la relation).

Le 3 mars 2012 17:45, Hélène PETIT  a écrit :
> Le 03/03/2012 15:54, PierreV a écrit :
>
>> Etant donné que OSM se base sur le nombre d'habitants, et qu'en France
>> nous
>> n'avons pas le détail des habitants au sein même d'une commune, comment on
>> fait?
>
>
> à la suite d'un débat l'année dernière sur le même sujet, j'ai fait le choix
> de ne plus rentrer "à la main" l'étiquette "population" et sa valeur
> associée ; voici pourquoi :
> 1) la population varie assez vite dans de nombreux endroits. Je ne vois pas
> comment je pourrais assurer la maintenance de cette donnée sur les centaines
> de communes dont j'ai rentré les frontières.
> 2) le nombre d'habitants est une information disponible en consultation
> automatisé auprès de l'insee.
> 3) le nombre de cartographes de terrain ( les "fourmis" qui travaillent à la
> main) sont une ressource rare, à laquelle il me semble un peu saugrenu de
> demander d'exécuter des tâches robotisables.
> 4) Il n'y a pas de réels standards dans OSM :
> http://wiki.openstreetmap.org/wiki/Category:Data_standards
> Le début de cette page est explicite, et je me range à son conseil : je mets
> donc mes deux tunes dans le bastringue, et ensuite je laisse faire
> l'entropie.
> 5) Il y a une sorte de chose qu'on pourrait prendre pour une sorte de
> redondance entre le nombre d'habitants et la valeur de l'étiquette "place" ;
> j'aime pas.
>
> Je suis un Schtroumf-Noir, et je le reste.
>
>
>
>
>
>
> ___
> 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] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
Dernière note: L'Insee a aussi défini des TRIRIS, qui sont des
regroupements d'IRIS (le plus souvent trois) utilisés pour certaines
statistiques pour lesquelles il y a risque de rupture du secret
statistique. Cela ne concerne pas les statistiques de population, mais
surtout les "IRIS économiques" (8% des IRIS sont des IRIS
économiques), car avec une seule IRIS risquerait de révéler des
données économiques d'une seule entreprise.

Je ne pense pas qu'il faille cartographier ces TRIRIS, leur définition
peut changer d'une année à l'autre selon les besoins nécessaire au
secret statistique et les données effectivement collectées pour une
année donnée. Il n'y a aucune garantie que ces TRIRIS soient
comparables d'une année à l'autre.

Le 3 mars 2012 17:40, Philippe Verdy  a écrit :
> Pour référence, regarder la définition des IRIS à l'Insee. Le
> découpage infracommunal en IRIS existe en principe dans toutes les
> communes dont la population totale atteint 10 000 habitants, et la
> plupart des communes de 5 000 à 10 000 habitants. (Les autres communes
> sont considérées dans leur totalité comme un seul IRIS).
>
> http://www.insee.fr/fr/methodes/default.asp?page=zonages/iris.htm
>
> Les IRIS seraient des données intéressantes à cartographier, pour le
> niveau administratif 10 dans OSM. Car c'est un niveau assez complet et
> clairement défini sur tout le territoire national.
>
> Le niveau 9 étant pour les arrondissements communaux dans une poignée
> de communes françaises comme Paris ou Marseille.
>
> Le niveau 11 concernant des zones plus petites (comme les quartiers,
> mais souvent très incomplets et mal définis), ou pouvant servir de
> base, quand ils ont une définition dans la commune concernée, aux
> regroupements nécessaires :
>
> - aux circonscriptions électorales (qui ne sont pas de type
> "boundary=administrative", mais de type "boundary=electoral",
> éventuellement complété avec "fr:boundary=f*" pour des types de
> circonscriptions pour l'assemblée nationale
> "fr:boundary=national_assembly", le sénat avec "fr:boundary=senate",
> le conseil régional avec "fr:boundary=region", ou le conseil général
> avec "fr:boundary=department"),
>
> - ou pouvant concerner des zonages spécifiques à la communauté de
> communes (qui les regroupe ensuite dans leurs zones de services
> qu'elles gèrent, ces regroupements souvent à la fois infracommunaux et
> intercommunaux ne correspondent pas à un niveau administratif dans
> OSM, mais pourraient être attribués à un type "fr:boundary=*"
> spécifique).
>
> Le 3 mars 2012 16:28, Philippe Verdy  a écrit :
>> Le 3 mars 2012 15:54, PierreV  a écrit :
>>> Par contre comment taguer les autres "regroupements" d'habitations?
>>> Etant donné que OSM se base sur le nombre d'habitants, et qu'en France nous
>>> n'avons pas le détail des habitants au sein même d'une commune, comment on
>>> fait?
>>
>> Ce n'est pas toujours vrai. Il y a d'abord le cas des « communes
>> associées » (qui ont des maires et conseils municipaux délégués pour
>> certains domaines normalement pris en charge par la commune) pour
>> lesquelles les statistiques de population sont encore disponibles de
>> façon distinctes de la commune « centre », en plus de la population
>> municipale totale.
>>
>> Ensuite, les communes assez peuplées ont un découpage zonal pour
>> lequel existe des données de population (ces données servent aussi au
>> découpage cantonal pour les communes couvertes par plusieurs cantons,
>> ou au découpage électoral pour les différentes circonscriptions
>> électorales, ou de façon encore plus fine pour répartir les bureaux de
>> votes) :
>>
>> Là encore l'Insee fournit bien les chiffres de population pour ces
>> découpages, même si elle ne donne pas toujours des tononymes officiels
>> (ce ne sont pas forcement des noms d'un ou plusieurs quartiers ou de
>> rues, éventuellement complété d'une précision géographique comme «
>> Nord/Sud » ou « centre/périphérie » ou « ville/campagne », ce peuvent
>> être de simples numéros d'ordre).

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Hélène PETIT 

Le 03/03/2012 15:54, PierreV a écrit :

Etant donné que OSM se base sur le nombre d'habitants, et qu'en France nous
n'avons pas le détail des habitants au sein même d'une commune, comment on
fait?


à la suite d'un débat l'année dernière sur le même sujet, j'ai fait le 
choix de ne plus rentrer "à la main" l'étiquette "population" et sa 
valeur associée ; voici pourquoi :
1) la population varie assez vite dans de nombreux endroits. Je ne vois 
pas comment je pourrais assurer la maintenance de cette donnée sur les 
centaines de communes dont j'ai rentré les frontières.
2) le nombre d'habitants est une information disponible en consultation 
automatisé auprès de l'insee.
3) le nombre de cartographes de terrain ( les "fourmis" qui travaillent 
à la main) sont une ressource rare, à laquelle il me semble un peu 
saugrenu de demander d'exécuter des tâches robotisables.

4) Il n'y a pas de réels standards dans OSM :
http://wiki.openstreetmap.org/wiki/Category:Data_standards
Le début de cette page est explicite, et je me range à son conseil : je 
mets donc mes deux tunes dans le bastringue, et ensuite je laisse faire 
l'entropie.
5) Il y a une sorte de chose qu'on pourrait prendre pour une sorte de 
redondance entre le nombre d'habitants et la valeur de l'étiquette 
"place" ; j'aime pas.


Je suis un Schtroumf-Noir, et je le reste.





___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
Pour référence, regarder la définition des IRIS à l'Insee. Le
découpage infracommunal en IRIS existe en principe dans toutes les
communes dont la population totale atteint 10 000 habitants, et la
plupart des communes de 5 000 à 10 000 habitants. (Les autres communes
sont considérées dans leur totalité comme un seul IRIS).

http://www.insee.fr/fr/methodes/default.asp?page=zonages/iris.htm

Les IRIS seraient des données intéressantes à cartographier, pour le
niveau administratif 10 dans OSM. Car c'est un niveau assez complet et
clairement défini sur tout le territoire national.

Le niveau 9 étant pour les arrondissements communaux dans une poignée
de communes françaises comme Paris ou Marseille.

Le niveau 11 concernant des zones plus petites (comme les quartiers,
mais souvent très incomplets et mal définis), ou pouvant servir de
base, quand ils ont une définition dans la commune concernée, aux
regroupements nécessaires :

- aux circonscriptions électorales (qui ne sont pas de type
"boundary=administrative", mais de type "boundary=electoral",
éventuellement complété avec "fr:boundary=f*" pour des types de
circonscriptions pour l'assemblée nationale
"fr:boundary=national_assembly", le sénat avec "fr:boundary=senate",
le conseil régional avec "fr:boundary=region", ou le conseil général
avec "fr:boundary=department"),

- ou pouvant concerner des zonages spécifiques à la communauté de
communes (qui les regroupe ensuite dans leurs zones de services
qu'elles gèrent, ces regroupements souvent à la fois infracommunaux et
intercommunaux ne correspondent pas à un niveau administratif dans
OSM, mais pourraient être attribués à un type "fr:boundary=*"
spécifique).

Le 3 mars 2012 16:28, Philippe Verdy  a écrit :
> Le 3 mars 2012 15:54, PierreV  a écrit :
>> Par contre comment taguer les autres "regroupements" d'habitations?
>> Etant donné que OSM se base sur le nombre d'habitants, et qu'en France nous
>> n'avons pas le détail des habitants au sein même d'une commune, comment on
>> fait?
>
> Ce n'est pas toujours vrai. Il y a d'abord le cas des « communes
> associées » (qui ont des maires et conseils municipaux délégués pour
> certains domaines normalement pris en charge par la commune) pour
> lesquelles les statistiques de population sont encore disponibles de
> façon distinctes de la commune « centre », en plus de la population
> municipale totale.
>
> Ensuite, les communes assez peuplées ont un découpage zonal pour
> lequel existe des données de population (ces données servent aussi au
> découpage cantonal pour les communes couvertes par plusieurs cantons,
> ou au découpage électoral pour les différentes circonscriptions
> électorales, ou de façon encore plus fine pour répartir les bureaux de
> votes) :
>
> Là encore l'Insee fournit bien les chiffres de population pour ces
> découpages, même si elle ne donne pas toujours des tononymes officiels
> (ce ne sont pas forcement des noms d'un ou plusieurs quartiers ou de
> rues, éventuellement complété d'une précision géographique comme «
> Nord/Sud » ou « centre/périphérie » ou « ville/campagne », ce peuvent
> être de simples numéros d'ordre).

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
Le 3 mars 2012 15:54, PierreV  a écrit :
> Par contre comment taguer les autres "regroupements" d'habitations?
> Etant donné que OSM se base sur le nombre d'habitants, et qu'en France nous
> n'avons pas le détail des habitants au sein même d'une commune, comment on
> fait?

Ce n'est pas toujours vrai. Il y a d'abord le cas des « communes
associées » (qui ont des maires et conseils municipaux délégués pour
certains domaines normalement pris en charge par la commune) pour
lesquelles les statistiques de population sont encore disponibles de
façon distinctes de la commune « centre », en plus de la population
municipale totale.

Ensuite, les communes assez peuplées ont un découpage zonal pour
lequel existe des données de population (ces données servent aussi au
découpage cantonal pour les communes couvertes par plusieurs cantons,
ou au découpage électoral pour les différentes circonscriptions
électorales, ou de façon encore plus fine pour répartir les bureaux de
votes) :

Là encore l'Insee fournit bien les chiffres de population pour ces
découpages, même si elle ne donne pas toujours des tononymes officiels
(ce ne sont pas forcement des noms d'un ou plusieurs quartiers ou de
rues, éventuellement complété d'une précision géographique comme «
Nord/Sud » ou « centre/périphérie » ou « ville/campagne », ce peuvent
être de simples numéros d'ordre).

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet PierreV 
Oup la discussion a dévié bien plus que rapidement que j'aurais pu
penser... en plus je suis totalement d'accord avec le fait que vous
soulevez: la limite d'une commune n'est pas du tout celle des panneaux
blancs entourés de rouge. mais bien celle que l'on peut trouver sur le
cadastre! je n'ai jamais dit le contraire...

Donc en fait vos réactions me font comprendre qu'il y a un autre problème:
sur l'utilisation du tag "place".

Bon si j'ai bien compris cela ne dérange pas du tout que sur la surface
d'une même commune on puisse trouver plusieurs "place=village": pour ca tout
le monde est d'accord. 

Par contre comment taguer les autres "regroupements" d'habitations?
Etant donné que OSM se base sur le nombre d'habitants, et qu'en France nous
n'avons pas le détail des habitants au sein même d'une commune, comment on
fait?
C'est pour cela que je pensait plutot me baser sur les différences
d'annonces avec les panneaux routiers:

- Panneau Blanc entouré de rouge: "Place=village" (ou supérieur)
http://g.co/maps/zsdcb
- Panneau Blanc entouré de rouge AVEC deuxieme ligne "commune de...":
"place=hamlet" http://g.co/maps/cbu8e
- Panneau Noir écriture blanc: "place=isolated_dwelling"
http://g.co/maps/yujqp


avant la mise en place de "place=isolated_dwelling" j'avais bien du mal a
taguer différemment les écarts avec "commune de" qui peuvent avoir plus de
100 habitants et les lieux dit de 2 ou 3 maisons...

voila au lieu de "disserter" sur un sujet dont tout le monde est d'accord
désolé de vouloir recentrer le débat sur nos désaccords

--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-fusionees-tp5532240p5533764.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

[OSM-talk-fr] Fwd: [contact] [Besoin d'aide technique] Onglet open street map dans qgis

2012-03-03 Par sujet Christian Quest 
Message reçu par le formulaire contact du site web...


-- Message transféré --
De :  
Date : 3 mars 2012 11:50
Objet : [contact] [Besoin d'aide technique] Onglet open street map dans qgis
À : cont...@openstreetmap.fr


Guillaume (dauge.guilla...@gmail.com) a envoyé un message en utilisant le
formulaire de contact suivant : http://openstreetmap.fr/contact.

Bonjour, je suis un sigiste débutant, et je viens d'installer Qgis version
1.7.4. J'aimerais savoir comment afficher l'onglet d'importation des données
open street map dans qgis. Là je ne le vois pas.
Merci pour votre réponse.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] forum: Telecharger les donn�es sur le serveur depuis Android

2012-03-03 Par sujet Philippe Verdy 
Visiblement le forum de letuffe.org a des problèmes pour transmettre
correctement le codage des caractères qu'il utilise dans ses envois
par courriel. Qui utilise encore les jeux de caractères non Unicode ?
Il serait temps de passer à UTF-8 comme tout le monde (plus de 60% du
web l'utilise, et les sites qui restent dans un jeu ISO 8859-* sont en
chûte libre, avec moins de 5% du contenu, et encore car cela comprend
des pages uniquement en US-ASCII (indiscernables de l'UTF-8, donc qui
ne posent pas de problème).

Le "problème" de la taille légèrement plus importante en UTF-8 n'en
est pas un pour les langues à  écriture latine, les capacités de
stockage ayant explosé depuis longtemps avec aussi une baisse
considérable de leur coût, comme aussi une progression fantastique des
temps d'accès et une réduction de l'énergie nécessaire (et donc des
coûts d'exploitation) avec les matériels actuels. On n'est plus dans
les années 80-90, ni même 2000, la question ne se pose plus et ceux
qui restent encore avec des jeux ISO 8859-* sont réellement à la
traîne et s'infligent plus de problèmes et de coûts vraiment pour
rien.

Je ne dis pas qu'il faut nécessairement convertir les historiques
(c'est long et coûteux à faire, à cause du volume total à convertir,
ça donne une charge de calcul importante des serveurs pendant la
conversion, et pas toujours sans problèmes même avec un outil
automatisé), mais fermer un forum utilisant un ancien codage pour en
ouvrir un autre utilisant le nouveau codage est une opération simple
et pas coûteuse ni longue à faire, qui permettra même de s'y retrouver
sans rien convertir du tout (les anciennes pages, si elles sont
gardées, seront séparées dans leur dossier qui peuvent gérer les
exceptions au codage universel).

D'autre part, l'agent automatique qui envoie les emails depuis un
forum doit être réglé pour qu'il indique explicitement le jeu utilisé
(même si c'est l'UTF-8).

Le 1 mars 2012 18:32, Yves  a écrit :
> Regarde httpurlconnexion ou quelquechose comme cela dans la doc android.
> Yves
>
>
> fo...@letuffe.org a écrit :
>>
>> Le message suivant :
>> ##
>> Bonjour � tous,
>>
>> Je dois d�velopper une application Java qui fonctionnera sous Android. Et
>> je dois donc pouvoir r�cup�rer des cartes et des fichiers osm directement
>> depuis mon application. En gros je veux obtenir le m�me r�sultat que sous
>> mon navigateur lorsque je demande
>> www.openstreetmap.org/api/0.6/map?bbox=-0.5,21.3,-0.4,21.4
>>
>> Comment puis-je le faire ?
>>
>> Merci pour votre aide.
>> 
>> a �t� post� sur le forum http://forum.openstreetmap.fr/viewforum.php?f=3
>> 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'avo
>>  ir 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
>
>
> ___
> 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] ITO maps

2012-03-03 Par sujet Philippe Verdy 
Sinon bravo pour la documentation détaillée des tags, et les
commentaires concernant les tags obsolètes, ambigus, en cours de
migration, ou non encore pris en charge. Ce site est remarquable de ce
point de vue là.

Si jamais ils intègrent une interface permettant ensuite de
contribuer, et avec une accélération de la disponibilité des tuiles,
ce site serait parfait et même meilleur que celui d'OSM. Car on a sur
le même écran (quand on sort du mode plein écran), toutes les infos de
documentation nécessaires (alors que sur le site OSM, on a des sites
séparés pour la carte navigable, pour l'éditeur Potlatch et pour la
documentation du wiki.  Il ne lui restera plus qu'à proposer des
traductions.

Bref je salue l'effort fourni. Et cela pourrait inspirer OSM... dont
le wiki est bien à la peine.

Le 3 mars 2012 14:20, Philippe Verdy  a écrit :
> En moyenne je n'arrive pas à avoir plus de 3 ou 4 tuiles sur les 16 à
> 20 nécessaires pour afficher une carte plein écran à un niveau de zoom
> donné, quel que soit le niveau de zoom. Toutes les autres tuiles
> restent en attente indéfiniment (et la fermeture de la page pour
> ensuite la recharger ne raffichera que les tuiles déjà dans le cache
> du navigateur (à condition de n'avoir pas purgé le cache sinon même
> celles-là n'apparaîtront plus).
>
> Visiblement le site a un limiteur de requêtes de tuiles par visiteur
> beaucoup trop agressif, qui donne ces délais infinis (au lieu de
> mettre un délai on dirait que la simple visite nous fait passer pour
> des abuseurs du système, on est vite bloqué totalement seulement en
> cherchant à afficher une zone donnée en dézoomant la zone par défaut
> pour se déplacer ailleurs et zoomer dessus.
>
> Le 3 mars 2012 14:13, Philippe Verdy  a écrit :
>> Outil quasiment inutilisable pour la France. Car beaucoup trop lent
>> (ou surchargé) pour le chargement de leurs tuiles. Apparemment l'outil
>> a d'abord été fait pour le Royaume-Uni, même même pour ce pays, c'est
>> d'une lenteur...
>>
>> C'est vrai qu'ils indiquent que c'est une version Bêta.
>>
>> Cependant j'aime bien leur idée de faire de nombreux calques
>> thématiques destinés à montrer des détails qui seraient difficiles à
>> voir dans des zones chargées. Dommage qu'ils n'aient pas ajouté la
>> possibilité de contribuer à partir de ces calques, qui sont tout de
>> même bien faits et montrent des tas de choses qu'on aurait oubliées.
>>
>> Le 3 mars 2012 14:01, Ab_fab  a écrit :
>>> bonjour,
>>>
>>> Une nouvelle moûture des cartes thématiques ITO est arrivée, avec de
>>> nouveaux thèmes
>>> http://www.itoworld.com/map/main
>>>
>>> --
>>> ab_fab
>>> "Il n'y a pas de pas perdus"
>>>
>>> ___
>>> 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] ITO maps

2012-03-03 Par sujet Philippe Verdy 
En moyenne je n'arrive pas à avoir plus de 3 ou 4 tuiles sur les 16 à
20 nécessaires pour afficher une carte plein écran à un niveau de zoom
donné, quel que soit le niveau de zoom. Toutes les autres tuiles
restent en attente indéfiniment (et la fermeture de la page pour
ensuite la recharger ne raffichera que les tuiles déjà dans le cache
du navigateur (à condition de n'avoir pas purgé le cache sinon même
celles-là n'apparaîtront plus).

Visiblement le site a un limiteur de requêtes de tuiles par visiteur
beaucoup trop agressif, qui donne ces délais infinis (au lieu de
mettre un délai on dirait que la simple visite nous fait passer pour
des abuseurs du système, on est vite bloqué totalement seulement en
cherchant à afficher une zone donnée en dézoomant la zone par défaut
pour se déplacer ailleurs et zoomer dessus.

Le 3 mars 2012 14:13, Philippe Verdy  a écrit :
> Outil quasiment inutilisable pour la France. Car beaucoup trop lent
> (ou surchargé) pour le chargement de leurs tuiles. Apparemment l'outil
> a d'abord été fait pour le Royaume-Uni, même même pour ce pays, c'est
> d'une lenteur...
>
> C'est vrai qu'ils indiquent que c'est une version Bêta.
>
> Cependant j'aime bien leur idée de faire de nombreux calques
> thématiques destinés à montrer des détails qui seraient difficiles à
> voir dans des zones chargées. Dommage qu'ils n'aient pas ajouté la
> possibilité de contribuer à partir de ces calques, qui sont tout de
> même bien faits et montrent des tas de choses qu'on aurait oubliées.
>
> Le 3 mars 2012 14:01, Ab_fab  a écrit :
>> bonjour,
>>
>> Une nouvelle moûture des cartes thématiques ITO est arrivée, avec de
>> nouveaux thèmes
>> http://www.itoworld.com/map/main
>>
>> --
>> ab_fab
>> "Il n'y a pas de pas perdus"
>>
>> ___
>> 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] ITO maps

2012-03-03 Par sujet Philippe Verdy 
Outil quasiment inutilisable pour la France. Car beaucoup trop lent
(ou surchargé) pour le chargement de leurs tuiles. Apparemment l'outil
a d'abord été fait pour le Royaume-Uni, même même pour ce pays, c'est
d'une lenteur...

C'est vrai qu'ils indiquent que c'est une version Bêta.

Cependant j'aime bien leur idée de faire de nombreux calques
thématiques destinés à montrer des détails qui seraient difficiles à
voir dans des zones chargées. Dommage qu'ils n'aient pas ajouté la
possibilité de contribuer à partir de ces calques, qui sont tout de
même bien faits et montrent des tas de choses qu'on aurait oubliées.

Le 3 mars 2012 14:01, Ab_fab  a écrit :
> bonjour,
>
> Une nouvelle moûture des cartes thématiques ITO est arrivée, avec de
> nouveaux thèmes
> http://www.itoworld.com/map/main
>
> --
> ab_fab
> "Il n'y a pas de pas perdus"
>
> ___
> 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

[OSM-talk-fr] ITO maps

2012-03-03 Par sujet Ab_fab 
bonjour,

Une nouvelle moûture des cartes thématiques ITO est arrivée, avec de
nouveaux thèmes
http://www.itoworld.com/map/main

-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Philippe Verdy 
Le 3 mars 2012 09:53, Vincent Pottier  a écrit :
> Les panneaux blancs entourés de rouge sont des panneaux de signalisation
> routière et non de signalisation administrative.

OK

> Ils ne désignent pas une commune mais une agglomération, au sens du code de
> la route, avec la réglementation qui s'y applique (maxspeed=50)

Pas tout à fait. car les mêmes panneaux se trouvent aussi à la
frontière communale quand on ne sort pas de l'agglomération. On a
alors les deux panneaux de sortie d'une commune et d'entrée dans une
autre.

De plus sur certaines routes, la limite peut rester à 70 (quand
l'agglomération est petite, sur des routes assez importantes), avec un
panneau supplémentaire le mentionnant, ou parfois plus (en arrivant
sur des rocades ou voies rapides protégées de grandes agglomérations,
le panneau de limitation à 50 étant reporté à la sortie de la rocade
en direction de la ville).

Enfin la définition des agglomérations ne vient pas du code de la
route, mais d'abord de statistiques urbaines établies par l'Insee (qui
détermine les agglomérations en fonction de la distance séparant deux
habitations ou bâtiments, et de la population occupant la zone ainsi
délimitée, et en éliminant certains trous de taille inférieure ou
proche à la distance maximale prise en compte pour les distances entre
les constructions, pour assurer une certaine continuité, et d'autres
critères, ce qui fait qu'on peut trouver des champs et des parcs au
milieu d'une agglomération).

Puis cette définition de l’Insee est mise en place plus tard, ou
anticipée aussi, au plan du code de la route par des arrêtés locaux
(car il peut arriver que l'agglomération commence avant ou après la
définition de l'Insee, le cas avant concernant des zones faisant
l'objet d'un aménagement commencé tel qu'un futur lotissement, dès
lors que les terrains ont été au moins viabilisés pour les rendre
constructibles).

C'est le préfet qui prend l'arrêté en concertation avec les communes
concernées (et maintenant plus souvent les communautés de communes ou
d'agglomération qui prennent en charge ce qui fut les plans
d'occupation des sols des communes mais maintenant des plans
d'aménagement urbain).

> La commune commence souvent bien avant le panneau, à la fin de la commune
> précédente, et finit là où commence celle des autres (tiens, ça me rappelle
> quelque chose)

Ok sauf l'exception notée ci-dessus concernant les agglomérations
pluricommunales (aussi appelées « conurbations »).

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes fusionées

2012-03-03 Par sujet Vincent Pottier 

Le 02/03/2012 22:17, PierreV a écrit :

Bonsoir,

J'ai une question de "logique":

Logiquement, en France nous devrions avoir un seul "place=village" par
"admin_level=8"

Non. Logiquement il ne doit y avoir qu'un seul "admin_center' par commune.
Mais le point "place" utilisé peut avoir n'importe quelle valeur, même 
isolated_dwelling en zone d'habitat dispersé si la mairie est au milieu 
des choux.
Et la valeur du tag name dans la relation commune peut ne pas être la 
même que dans le point place. Notamment dans le cas d'une commune fusionnée.
Par exemple la commune "Saint-Jean-Saint-Paul" dans l'Aveyron (tag 
name=Saint-Jean-Saint-Paul) dans la relation) aura pour admin_center le 
point place=village + name=Saint-Jean-d'Alcas, et le village 
Saint-Paul-des-Fons, sur la même commune a son propre point : 
place=village + name=Saint-Paul-des-Fons

Les écarts (panneau blanc entourés de rouge, avec en deuxième ligne "commune
de...") devraient être tagués "place=hamlet" et les lieux dits (petits
panneaux noir) en "place=isolated_dwelling" (corrigez moi si je me
trompe...)
Les panneaux blancs entourés de rouge sont des panneaux de signalisation 
routière et non de signalisation administrative.
Ils ne désignent pas une commune mais une agglomération, au sens du code 
de la route, avec la réglementation qui s'y applique (maxspeed=50)
La commune commence souvent bien avant le panneau, à la fin de la 
commune précédente, et finit là où commence celle des autres (tiens, ça 
me rappelle quelque chose)


--
FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr