date:20150430

Le cadastre de Lille répond encore à la question: les zones cadastrales
font toujours référence aux codes INSEE de Lomme et Hélemme qui sont
toujours valides même si ce ne sont plus des communes de plein exercice
(plsu de conseil municipal et plus des collectivités territoriales), ce
sont toujours bel et bien des communes, avec leur état-civil, leur maire
(délégué), et leur propre cadastre maintenu séparé (même s'il est géré
administrativement par les services municipaux de la commune de Lille).

Ce cas ne se présente pas qu'à Lille mais dans toutes les communes
associées de France.

En revanche si cela répond à la question administrative (et au fait que les
rues hjomonymes n'ont pas été renommées après cette "fusion" qui n'en est
pas une), cela ne dit rien du découpage postal (qui ne suit pas toujours
les limites administratives concernant les codes postaux).

Bref l'unicité du nom de rue administratif reste garantie avec le code
INSEE (en prenant le code INSEE effectif de la commune associée, toujours
valide, et non pas celui de la commune nouvelle de plein exercice). Donc
pour ça il faut s'appuyer non pas sur le fichier des codes INSEE des
communes-collectivités mais celui plus complet des codes INSEE des
état-civils.

L'insee d'ailleurs fournit ce fichier complet (avec l'indication
complémentaire du type de commune: commune simple, commune nouvelle en
association, commune associée); L'insee fournit aussi, à part le fichier
des anciens codes Insee (ceux des anciennes communes qui ne sont plus ni
des collectivités, ni des communes associées, et qui n'ont plus
d'état-civil ni de cadastre propre) avec le code Insee de la nouvelle
commune

[note]
  * On a deux exceptions en outre-mer avec Saint-Martin et Sain-Barthélemy
qui ne sont plus des communes, n'ont plus de maire, mais ont toujours un
état-civil dont un code Insee valide
  * De même pour les collectivités de Wallis-et-Futuna qui ne comptent
aucune commune mais ont bien des état-civils dans les 3 "circonscriptions"
du conseil territorial, correspondant aux territoires des trois royaumes
coutumiers; ces 3 criconscriptions pourraient être élargies à 5 dans les 3
districts coutumiers du royaume futunien (les deux royaumes wallisiens
n'étant pas découpés en districts), mais actuellement le site du ministère
de l'outremer ne parle que des 3 circonscriptions et pas encore de 5, et
parle sinon des deux "délégations" de l'archipel (à Nouméa et à Paris) pour
gérer l'état-civil des wallisiens et futuniens qui sont nés ou qui résident
hors de l'archipel et qui désirent conserver leur statut personnel
coutumier ; sinon c'est l'état-civil du seul lieu de naissance qui compte
pour le statut civil commun, et ce sont seulement ces 3 circonscriptions
qui s'en occupent, faute de commune (ou sinon les ambassades et consulats
de France uniquement comme intermédiaire des 3 circonscriptions, via la
délégation de l'archipel à Paris, ou via la délégation de l'archipel à
Nouméa pour ceux qui résident dans la zone océanienne hors de l'archipel
lui-même).

Je suis tout de même curieux de voir comme l'Insee codifie plus précisément
les "localités" de Wallis-et-Futuna puisqu'il n'y a pas de communes: parmi
les 3 royaumes, les 3 districts futuniens, les villages dotés d'une
chefferie coutumière, et sinon les autres villages ou hameaux, tout est
coutumier en dehors des 3 "circonscriptions" du conseil territorial qui
semblent être le plus bas niveau territorial où peut être géré à la fois le
droit civil commun pour tout le monde (nationalité et citoyenneté
républicaine, état-civil, fiscalité commune, justice civile, domaine public
de droit commun, école publique de la république, enseignement supérieur
public, radio-télévision publique, santé publique, sécurité civile,
police/gendarmerie, zone de défense, eaux territoriales, ZEE, et relations
internationales de proximité du conseil territorial...), et le droit
coutumier pour ceux qui relèvent de ce droit (ainsi que pour le
domaine territorial public de droit coutumier, comprenant les propriétés
consultatives et judiciaires des royaumes et chefferies de districts et de
villages, et les propriétés et autres équipements collectifs coutumiers,
dont les écoles publiques coutumières, les espaces et ressources naturelles
gérés par ces chefferies).
[/note]

Concernant ensuite le mapping de ces codes INSEE élargis vers les codes
postaux, c'est une autre histoire car là on peut se retrouver à nouveau
avec des homonymies de rues (pour lesquelles La Poste dans le passé
demandait de suffixer le nom du bureau distributeur ou d'ajouter une ligne
d'adresse avant... mais maintenant elle recommande d'utiliser plutôt le nom
de la commune administrative (pas la commune-collectivité de plein exercice
mais celle de la commune associée le cas échéant), ce qui évite des
adresses à rallonge et permet à la dernière ligne d'adresse de rester dans
les limites de longueur (sans risque de troncature des suffixes de
précision) et sans avoir à utiliser une autre l

Re: [OSM-talk-fr] Normalisation du tag antenne

Note: je n'ai rien précisé concernant la façon de créer un échappement pour
les crochets, accolades, guillemets, apostrophes, et les pipe, virgules ou
point-virgules : il faudrait juste réserve le backslash ou d'un caractère
conventionel non réservé :
- \\ pour le backslash \ lui même
- \| pour le pipe |
- \= pour le signe égal =
- \[ et \] pour les crochets [ et ]
- \{ et \} pour les accolades { et }
- \s (semicolon) pour le point-virgule ; et non pas \; afin de ne pas
entrer en conflit avec les point-virgules séparateurs par défaut des listes
non ordonnées d'OSM)

Et pour le cas où des chaines déjà entre "guillemets" ou entre
'apostrophes' sont utilisées:
- \q (quote) pour les guillemets doubles ASCII "
- \a (apos) pour les guillemets doubles ASCII '

Rien de prévu pour les échappements Unicode (ceux qui y tiennent pourront
ajouter \xNN ou \u ou \UNN), le but étant de coder directement les
caractères du texte si possible et d'utiliser sinon les échappements plus
compacts à deux caractères...

Avec ça on a tout pour imiter JSON, mais en plus compact et sans distinguer
les types numériques et chaines (il n'y a qu'un seul type d'atome : les
chaînes).

Les schémas qui voudraient distinguer les types d'atomes devraient coder ça
dans les atomes-chaines par une convention comme "type:valeur" (un peut
comme le fait PHP pour sérialiser ses données), par exemple "i:10" pour
indiquer l'entier 10 (nombre de bits non limité), "n:10" pour le nombre
flottant 10 (précision non limitée), "s:10" pour indiquer la chaîne "10",
"n:" pour indiquer une valeur nil, "d:date" pour une date dans un format
compatible ISO8601 (avec séparateurs de champs de date optionnels pour que
ce soit encore plus compact)...

Le 1 mai 2015 01:17, Philippe Verdy  a écrit :

> Le 1 mai 2015 00:35, dHuy Pierre  a écrit :
>
>> @Verdy: Heureux de te voir enfin, j'étais presqu'étoné de ne pas te lire.
>> Cette propal de nomenclature est vraiment bonne.
>>
>
> Note: je n'ai pas voulu taper "gags" mais "tags" (mais sur le coup le
> smartphone que j'ai utilisé temporairement, le temps d'une indisponibilité
> du système sur PC, n'en a fait qu'à sa tête malgré plusieurs corrections
> successives de ce mot, il a encore été remplacé contre ma volonté lors de
> l'envoi...)
>
> Personnellement je n'ai jamais aimé le fait de mêler deux types de
> séparateurs dans les tags lanes, c'est très peu lisible et trompeur. Et
> j'aurais préféré un codage de type JSON (mais encore un peu plus compact),
> sans aucun point-virgule (sauf si la structure principale est celle d'une
> liste non ordonnée: aucun point-virgule dans les éléments)
>
> Bref si on veut tout mettre dans un seul tag, permettre alors l'usage des
> accolades, et dans ce cas dans les accolades permettre d'utilier
> guillements et apostrophes ASCII pour encadrer des chaines (mais ne
> contenant aucun point-virgule qui devraient utiliser un échappement)
>
> Les valeurs structurées et sous-structures ne seraient que des listes non
> ordonnées (entre accolades, séparées par des pipes ou virgules), ou
> ordonnées/indexés (entre crochets, séparées aussi par des pipes, avec un
> éventuel signe égal pour nommer/indexer le champ), et contrairement à JSON,
> les guillemets seraient presque toujours évitables, et il n'y aurait qu'un
> seul type d'atome: les chaines, et pas de nombres en tant que tels
>
> Les séparateurs seraient également évitables s'il y a des crochets ou
> accolades avant ou après, pour que ce soit encore plus compact. Pour cet
> exemple cela donnerait:
>
> operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE
> MOBILE{UMTS 900|UMTS 2100|LTE 2600}]}
>
> Mais puisqu'ici la structure externe est une liste non ordonnée, on peut
> aussi éviter les accolades externes et alors utiliser les points-virgules
> habituels d'OSM, et supprimer aussi les crochets encadrant chaque élément
> de la liste non ordonnée quant ils sont eux-même des listes ordonnées:
>
> operator=TDF{FM|FH};Opérateur privé{PMR};SNCF{GSM R};FREE MOBILE{UMTS 900|UMTS
> 2100|LTE 2600}
>
> Et voilà alors notre format JSON-like, ultra compact, adapté pour OSM,
> mais toujours très lisible !
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

Le 1 mai 2015 00:35, dHuy Pierre  a écrit :

> @Verdy: Heureux de te voir enfin, j'étais presqu'étoné de ne pas te lire.
> Cette propal de nomenclature est vraiment bonne.
>

Note: je n'ai pas voulu taper "gags" mais "tags" (mais sur le coup le
smartphone que j'ai utilisé temporairement, le temps d'une indisponibilité
du système sur PC, n'en a fait qu'à sa tête malgré plusieurs corrections
successives de ce mot, il a encore été remplacé contre ma volonté lors de
l'envoi...)

Personnellement je n'ai jamais aimé le fait de mêler deux types de
séparateurs dans les tags lanes, c'est très peu lisible et trompeur. Et
j'aurais préféré un codage de type JSON (mais encore un peu plus compact),
sans aucun point-virgule (sauf si la structure principale est celle d'une
liste non ordonnée: aucun point-virgule dans les éléments)

Bref si on veut tout mettre dans un seul tag, permettre alors l'usage des
accolades, et dans ce cas dans les accolades permettre d'utilier
guillements et apostrophes ASCII pour encadrer des chaines (mais ne
contenant aucun point-virgule qui devraient utiliser un échappement)

Les valeurs structurées et sous-structures ne seraient que des listes non
ordonnées (entre accolades, séparées par des pipes ou virgules), ou
ordonnées/indexés (entre crochets, séparées aussi par des pipes, avec un
éventuel signe égal pour nommer/indexer le champ), et contrairement à JSON,
les guillemets seraient presque toujours évitables, et il n'y aurait qu'un
seul type d'atome: les chaines, et pas de nombres en tant que tels

Les séparateurs seraient également évitables s'il y a des crochets ou
accolades avant ou après, pour que ce soit encore plus compact. Pour cet
exemple cela donnerait:

operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}

Mais puisqu'ici la structure externe est une liste non ordonnée, on peut
aussi éviter les accolades externes et alors utiliser les points-virgules
habituels d'OSM, et supprimer aussi les crochets encadrant chaque élément
de la liste non ordonnée quant ils sont eux-même des listes ordonnées:

operator=TDF{FM|FH};Opérateur privé{PMR};SNCF{GSM R};FREE MOBILE{UMTS 900|UMTS
2100|LTE 2600}

Et voilà alors notre format JSON-like, ultra compact, adapté pour OSM, mais
toujours très lisible !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Par sujet Jean-Marc Liotier


On 01/05/2015 00:35, dHuy Pierre wrote:
@Liotier: Forme et emplacement d'antenne on est d'accord sauf qu'à 
voir la liste des type j'aurais besoin d'un coup de main si on veut 
proposer une vraie liste, tu peux faire ça le pad?


De retour au bureau lundi je devrais avoir moyen de mettre la main sur 
une typologie d'antennes pour un réseau mobile (en espérant que ce 
soient des types génériques et non des modèles de constructeurs) - et je 
devrais pouvoir contribuer quelques types supplémentaires.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

@Verdy: Heureux de te voir enfin, j'étais presqu'étoné de ne pas te lire. Cette 
propal de nomenclature est vraiment bonne. Merci Jérôme pour le coup, je ne 
vois pas comment mieux lier (quelqu'un avait proposé antenna:1...n mais il est 
clair que ce tag était invivable.
@Liostier: Forme et emplacement d'antenne on est d'accord sauf qu'à voir la 
liste des type j'aurais besoin d'un coup de main si on veut proposer une vraie 
liste, tu peux faire ça le pad?Autrement je continue de considérer qu'il faut 
distinguer les antennes en fonction de leur émission. La cartographie ne passe 
pas que par le visuel et la connaissance de certains réseau peut être 
exploitable pour un usage civil (cf use case sur le pad et dans la ML). J'ai 
officiellement barré les bandes de fréquences, et les directions. On en reste 
du coup au draft initial de opérateurs, type de réseau, et type d'antenne (plus 
tag optionnel avec hidden, height, antenna:dimension et ele)
 


 Le Vendredi 1 mai 2015 0h18, Philippe Verdy  a écrit :
   

 
Le 30 avr. 2015 18:42, "Christian Quest"  a écrit :
> Le 30/04/2015 18:07, Jérôme Amagat a écrit :
>> operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM
>> "reseau" =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE 
>> 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100|
>>
>
> La convention sur OSM est de séparer par des ;Oui mais uniquement pour des 
> listes non ordonnées. Là Jérôme voulait lier l'ordre des deux listes.Les 
> traits verticaux sont utilisés dans ce cas pour les listes ordonnées de 
> lanes.Seulement je trouve ça très peu lisible. Il serait plus pertinent de 
> grouper les données propre à chaque opérateur au nom de cet opérateur et en 
> séparant alors les opérateurs sur des gags distincts.Cela donnerait un truc 
> du genre:operator:1=TDF|FM;FH
operator:2=Opérateur privé|PMR
operator:3=SNCF|GSM R
operator:4=FREE MOBILE|UMTS 900;UMTS 2100;LTE 2600
etc.Les séparateurs n'ont pas le même rôle et un pipe indique l'ordre des 
champs (nom d'operateur, types de reseau) lesquels peuvent encore inclure en 
valeur des listes non ordonnées séparées par points-virgules...Les indices 
numériques donnés à chaque opérateur sont ordonnés mais en fait 
arbitrairement.Dès que ça se complique de toute façon on se retrouve avec 
plusieurs tags. Sinon il faudrait admetttre des valeurs dans un type structuré 
comme JSON, voire XML en plus verbeux encore...

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


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

Re: [OSM-talk-fr] Normalisation du tag antenne

Le 30 avr. 2015 18:42, "Christian Quest"  a écrit :
> Le 30/04/2015 18:07, Jérôme Amagat a écrit :
>> operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM
>> "reseau" =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE
800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100|
>>
>
> La convention sur OSM est de séparer par des ;

Oui mais uniquement pour des listes non ordonnées. Là Jérôme voulait lier
l'ordre des deux listes.

Les traits verticaux sont utilisés dans ce cas pour les listes ordonnées de
lanes.

Seulement je trouve ça très peu lisible. Il serait plus pertinent de
grouper les données propre à chaque opérateur au nom de cet opérateur et en
séparant alors les opérateurs sur des gags distincts.

Cela donnerait un truc du genre:

operator:1=TDF|FM;FH
operator:2=Opérateur privé|PMR
operator:3=SNCF|GSM R
operator:4=FREE MOBILE|UMTS 900;UMTS 2100;LTE 2600
etc.

Les séparateurs n'ont pas le même rôle et un pipe indique l'ordre des
champs (nom d'operateur, types de reseau) lesquels peuvent encore inclure
en valeur des listes non ordonnées séparées par points-virgules...

Les indices numériques donnés à chaque opérateur sont ordonnés mais en fait
arbitrairement.

Dès que ça se complique de toute façon on se retrouve avec plusieurs tags.
Sinon il faudrait admetttre des valeurs dans un type structuré comme JSON,
voire XML en plus verbeux encore...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Par sujet Jean-Marc Liotier

Je prend la discussion en cours de route... Mais si je puis me permettre 
quelques suggestions...


Commencez pas border un consensus concernant les artefacts physiques 
observables visuellement - types d'antennes par exemple. C'est un but 
atteignable et ce sera déjà beau.


Veillez à insister sur la distinction entre l'antenne et son support (je 
vois souvent des confusions) - ça permettra de traiter proprement le cas 
très courant du support garni d'une palanquée d'antennes diverses, tout 
en simplifiant la taxonomie (mât+yagi, pylône+parabole, clocher+omni etc.)


Concernant les caractéristiques radio... Vous êtes dingues. Ambitieux, 
courageux et tout ça - mais dingues quand même. Les opérateurs ne sont 
même pas complètement certains de ce qu'ils ont sur le terrain et ça 
bouge tout le temps... J'ai mal pour vous rien que d'y penser. Collez 
l'identifiant ANFR comme lien vers les détails (laissez les applications 
utilisatrices construire l'URL) et oubliez le reste - pour votre bien !


Oubliez aussi le site radio - c'est un identifiant impossible à vérifier 
visuellement. Vous pouvez évidemment identifier le site physique (un 
shelter, un bâtiment, une salle - cf. les débats précédents concernant 
les sites de télécommunications) mais la couche radio est purement 
logique - et donc reconfigurable... Laissez l'utilisateur lire 
l'identifiant ANFR de l'antenne et suivre le fil pour trouver à quel 
site elle appartient.



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

Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales

2015-04-30 Par sujet « Ano59 »


Bonjour !

Ayant pas mal cartographié dans la zone, je confirme cet état de 
fait. Dans les tuiles téléchargées depuis le cadastre la commune Lille 
forme un bloc incluant Lomme et Hellemmes, deux communes bien distinctes 
auparavant. Cela me posait quelques soucis au niveau des noms de rue car 
en effet certains noms sont identiques. Je prendrai comme exemple la rue 
Franklin.

Lille : http://www.openstreetmap.org/way/42736758
Lomme : http://www.openstreetmap.org/way/319963911

En général dans ce genre de cas le fichier FANTOIR fait la 
distinction en ajoutant le nom de la commune (non-Lilloise) juste après 
le nom de rue. Ainsi, concernant Lille : 
http://cadastre.openstreetmap.fr/fantoir/#insee=59350

Lille : "Rue Franklin" - 593503587M
Lomme : "Rue Franklin Lomme" - 593509455R - D'ailleurs elle n'est 
plus comptabilisée comme reconnue, c'est étrange


Auparavant je donnais aux ways le même nom, à savoir ici "Rue 
Franklin", mais cette pratique perturbait grandement BANO (qui se 
retrouvait avec deux voies identiques aux références FANTOIR 
différentes) et pouvait porter à confusion dans le cas de quelqu'un 
recherchant cette rue dans OSM. J'ai donc rejoint la pratique du FANTOIR 
en indiquant le nom de la commune (non-Lilloise) le cas échéant.


Sinon au sujet des codes postaux, en vous avertissant en préalable 
que je n'y connais quasiment rien en la matière, j'incite à la prudence 
avant d'associer un code postal avec une zone géographique. Mon quartier 
(bien Lillois) est par exemple concerné par un code postal qui semble 
"historique", le 59800, et qui est redondant avec le 59000.


Cordialement,
« Ano59 ».

Le 30/04/2015 14:40, kinju a écrit :
J'ai constaté qu'ils avaient des soucis pour gérer les communes 
associées.


Par exemple dans le Nord, la commune de Lomme (59160) est associée à 
Lille, donc administrativement Lomme n'existe pas.


Sur les sites administratifs (Pôle Emploi, Impôts etc.) lorsque l'on 
tape "59160" ça propose les villes Lille et Capinghem, mais pas Lomme. 
Or, d'un point de vue postal, Lomme existe bien.


D'ailleurs certaines rues / places existent à la fois à Lille et à 
Lomme, donc d'un point de vue purement administratif, il y a deux rue 
Albert Machin Bidule à Lille.


2015-04-30 9:36 GMT+02:00 Romain MEHUT >:


Bonjour,

Voici le lien d'un article intitulé "Sans adresse postale
normalisée, point de très haut débit?" où il est question de la BAN

http://www.localtis.info/cs/ContentServer?pagename=Localtis/LOCActu/ArticleActualite&cid=1250268831944

Romain

Le 16 avril 2015 23:17, Christian Quest mailto:cqu...@openstreetmap.fr>> a écrit :

Le 16/04/2015 21:54, Frédéric Rodrigo a écrit :

> - seuls 2 champs ne sont pas proposés en ODbL: le libellé
AFNOR et le libellé d'acheminement

Question peut être un peu bête. Mais le libellé AFNOR est
calculée, non ? Il peut donc être récréé ?



Il me semble, mais pour OSM ça n'a pas franchement d'intérêt
vu que c'est finalement une dégradation du nom complet.
L'important c'est d'avoir un nom correct au départ et ça c'est
pas garanti à 100%

Il va falloir évaluer au plus serré le contenu de la BAN avant
de reprendre des données pour les insérer dans OSM, tout comme
il faut être quand même prudent avec les données du cadastre
récupérées par BANO.

-- 
Christian Quest - OpenStreetMap France



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



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




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


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

Re: [OSM-talk-fr] Normalisation du tag antenne

Alors le type de réseau, l'id anfr (ou autres), le type d'antenne (ça peut être
carrément utile pour le repérage) et les opérateurs. Le tout placé via le tag
antenna=yes.Comment gérer une antenne isolée sur un batiment?

Le Jeudi 30 avril 2015 19h55, Eric Debeau a écrit :

Salut

Pour répondre à Pierre, effectivement il ya les données de hauteur des antennes
par rapport au sol...Le champ m'avait échappé...

Sinon, je suis comme Jérome, je ne vois pas comment on pourrait mettre un point
par antenne dans OSM.

Je pense que mettre un résumé par support comme le suggère Christian suffit
largement. L'ID ANFR à utiliser serait l'ID du support que l'on trouve dans le
fichier support.txt (SUP_ID) et qui permet ensuite de retrouver les infos
complémentaires sur le site cartoradio si besoin.

Je pense que dans OSM, faut mettre que les infos "utiles" et "stables".

Si j'ai besoin des données complètes, je vais chercher directement dans les
données ANFR et pas dans OSM !

Eric

2015-04-30 19:16 GMT+02:00 Christian Quest :

Le 30/04/2015 19:08, Jérôme Amagat a écrit :

Dans un precedant mail tu ecris : "Je verrai bien un "résumé" dans OSM qui
indique:
- le pylone,
- l'usage (GSM, 2/3/4G, autre)
- les opérateurs...
- l'ID ANFR pour aller chercher le reste des infos dans une base plus
détaillée et qui sera sûrement mieux mises à jour qu'OSM ! "
Le problème c'est que chaque opérateur fait un usage qui peut être bien
différent des autres. Dans l'exemple même free et bouygues ne font pas la même
chose (le GSM). ce que je proposais c'est de lier opérateur et usage. je sais
bien que l'on utilise les ";" mais c'est pas toujours le cas :
http://wiki.openstreetmap.org/wiki/Lanes
operator =RESEAU PRIVE| TDF | SNCF Réseau | FREE MOBILE
| IFW | BOUYGUES TELECOM "reseau" =PMR |
FM;FH | GSM R | UMTS 900;UMTS 2100;LTE 2600 | BLR 3 GHZ | FH;LTE
800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100

Justement, je voyais un résumé plus... résumé ;)

La liste des opérateurs, ça me semble pertinent.
Ensuite le détail par opérateur du type d'usage, ça me semble déjà aller trop
loin.
Savoir qu'un pylône sert pour du GSM quel que soit l'opérateur est un niveau
de détail à peu près gérable dans OSM (j'entends par là maintenable, parce que
pour le côté vérifiable faut être affuté). Après pour plus, il y a les données
détaillées.

Ça ne vous semble pas suffisant ?

--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Par sujet Eric Debeau

Salut

Pour répondre à Pierre, effectivement il ya les données de hauteur des
antennes par rapport au sol...Le champ m'avait échappé...

Sinon, je suis comme Jérome, je ne vois pas comment on pourrait mettre un
point par antenne dans OSM.

Je pense que mettre un résumé par support comme le suggère Christian suffit
largement. L'ID ANFR à utiliser serait l'ID du support que l'on trouve dans
le fichier support.txt (SUP_ID) et qui permet ensuite de retrouver les
infos complémentaires sur le site cartoradio si besoin.

Je pense que dans OSM, faut mettre que les infos "utiles" et "stables".

Si j'ai besoin des données complètes, je vais chercher directement dans les
données ANFR et pas dans OSM !

Eric

2015-04-30 19:16 GMT+02:00 Christian Quest :

>
>
> Le 30/04/2015 19:08, Jérôme Amagat a écrit :
>
>   Dans un precedant mail tu ecris :
> "Je verrai bien un "résumé" dans OSM qui indique:
> - le pylone,
> - l'usage (GSM, 2/3/4G, autre)
> - les opérateurs...
> - l'ID ANFR pour aller chercher le reste des infos dans une base plus
> détaillée et qui sera sûrement mieux mises à jour qu'OSM ! "
>
>  Le problème c'est que chaque opérateur fait un usage qui peut être bien
> différent des autres. Dans l'exemple même free et bouygues ne font pas la
> même chose (le GSM).
> ce que je proposais c'est de lier opérateur et usage.
> je sais bien que l'on utilise les ";" mais c'est pas toujours le cas :
> http://wiki.openstreetmap.org/wiki/Lanes
>
>  operator =RESEAU PRIVE*|* TDF *|* SNCF Réseau *|* FREE MOBILE
>  *|* IFW   *|* BOUYGUES TELECOM
> "reseau" =PMR *|* FM;FH *|* GSM R   *|* UMTS
> 900;UMTS 2100;LTE 2600 *|* BLR 3 GHZ *|* FH;LTE 800;LTE 1800;LTE 2600;GSM
> 900;GSM 1800;UMTS 2100
>
>
>
> Justement, je voyais un résumé plus... résumé ;)
>
> La liste des opérateurs, ça me semble pertinent.
> Ensuite le détail par opérateur du type d'usage, ça me semble déjà aller
> trop loin.
> Savoir qu'un pylône sert pour du GSM quel que soit l'opérateur est un
> niveau de détail à peu près gérable dans OSM (j'entends par là maintenable,
> parce que pour le côté vérifiable faut être affuté). Après pour plus, il y
> a les données détaillées.
>
> Ça ne vous semble pas suffisant ?
>
> --
> Christian Quest - OpenStreetMap France
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] En Inde, des enfants veulent transformer les bidonvilles par la cartographie

2015-04-30 Par sujet Shohreh

"Tous les enfants aiment dessiner. Mais en Inde, de jeunes résidents des
bidonvilles utilisent leurs talents d’artistes pour provoquer des
changements urbains.

Dans le cadre d’une campagne civique centrée sur des clubs d’enfants, des
groupes de jeunes créent des « cartes sociales » détaillées de leurs
quartiers marginalisés avec l’objectif de partager leurs inquiétudes sur
l’espace public."

http://visionscarto.net/inde-cartographie-enfants



--
View this message in context: 
http://gis.19327.n5.nabble.com/En-Inde-des-enfants-veulent-transformer-les-bidonvilles-par-la-cartographie-tp5842600.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Normalisation du tag antenne



Le 30/04/2015 19:08, Jérôme Amagat a écrit :
> Dans un precedant mail tu ecris :
> "Je verrai bien un "résumé" dans OSM qui indique:
> - le pylone,
> - l'usage (GSM, 2/3/4G, autre)
> - les opérateurs...
> - l'ID ANFR pour aller chercher le reste des infos dans une base plus
> détaillée et qui sera sûrement mieux mises à jour qu'OSM ! "
>
> Le problème c'est que chaque opérateur fait un usage qui peut être
> bien différent des autres. Dans l'exemple même free et bouygues ne
> font pas la même chose (le GSM).
> ce que je proposais c'est de lier opérateur et usage.
> je sais bien que l'on utilise les ";" mais c'est pas toujours le cas
> : http://wiki.openstreetmap.org/wiki/Lanes
>
> operator =RESEAU PRIVE*|* TDF *|* SNCF Réseau *|* FREE MOBILE
>*|* IFW   *|* BOUYGUES TELECOM
> "reseau" =PMR *|* FM;FH *|* GSM R   *|* UMTS
> 900;UMTS 2100;LTE 2600 *|* BLR 3 GHZ *|* FH;LTE 800;LTE 1800;LTE
> 2600;GSM 900;GSM 1800;UMTS 2100
>
>

Justement, je voyais un résumé plus... résumé ;)

La liste des opérateurs, ça me semble pertinent.
Ensuite le détail par opérateur du type d'usage, ça me semble déjà aller
trop loin.
Savoir qu'un pylône sert pour du GSM quel que soit l'opérateur est un
niveau de détail à peu près gérable dans OSM (j'entends par là
maintenable, parce que pour le côté vérifiable faut être affuté). Après
pour plus, il y a les données détaillées.

Ça ne vous semble pas suffisant ?

-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Par sujet Jérôme Amagat

Le 30 avril 2015 18:41, Christian Quest  a écrit :

>
>
> Le 30/04/2015 18:07, Jérôme Amagat a écrit :
>
> man_made=antenna
> est-ce que man_made est une bonne solution? beaucoup des antenne sont sur
> une tour, un pylône qui lui devrai être tagger en man_made.
> pourquoi pas seulement ajouté antenna=yes sur le support? supprimé
> complètement man_made=antenna ne serai t elle pas une meilleur solution
> pour éviter des confusions?
>
>  l'id anfr : il faut voir de quoi on parle. dans le fichier libéré, des
> id il y en a plusieurs : un pour chaque support, station, antenne, émetteur
> et bande. et le "numéro d'identification de l’installation sur Cartoradio".
>
>  Une autre question : moi je pars du principe que l'on ne peut pas, pour
> un pylône, placer plusieurs points dans osm. j'ai raison?
>
>  je repart sur l'exemple que j'ai donner plus haut :
> je verais bien ça :
> man_made=tower (ou autre)
> antenna=yes
> ref:cartoradio=...
>  operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM
> "reseau" =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE
> 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100|
>
>
> La convention sur OSM est de séparer par des ;
>
> Donc plutôt:
> operator=RESEAU PRIVE;TDF;SNCF Réseau;FREE MOBILE;IFW;BOUYGUES TELECOM
>
>
>   utiliser des "|" comme pour les lanes sur les routes permet de donner
> des infos sur chaque operator.
> je ne vois pas comment on pourrait en mettre plus sans rendre le truc
> incompréhensible.
>
>
> Franchement, je ne vois pas l'intérêt de recopier toutes ces données
> librement disponibles dans OSM. Inutilement complexe, les mises à jour
> manuelles ne seront sûrement jamais faites... mieux vaut se référer à la
> source et donc correctement pointer vers elle.
> Les ré-utilisateurs potentiels préféreront sûrement reprendre directement
> les données de l'ANFR.
>

Dans un precedant mail tu ecris :
"Je verrai bien un "résumé" dans OSM qui indique:
- le pylone,
- l'usage (GSM, 2/3/4G, autre)
- les opérateurs...
- l'ID ANFR pour aller chercher le reste des infos dans une base plus
détaillée et qui sera sûrement mieux mises à jour qu'OSM ! "

Le problème c'est que chaque opérateur fait un usage qui peut être bien
différent des autres. Dans l'exemple même free et bouygues ne font pas la
même chose (le GSM).
ce que je proposais c'est de lier opérateur et usage.
je sais bien que l'on utilise les ";" mais c'est pas toujours le cas :
http://wiki.openstreetmap.org/wiki/Lanes

operator =RESEAU PRIVE*|* TDF *|* SNCF Réseau *|* FREE MOBILE
 *|* IFW   *|* BOUYGUES TELECOM
"reseau" =PMR *|* FM;FH *|* GSM R   *|* UMTS
900;UMTS 2100;LTE 2600 *|* BLR 3 GHZ *|* FH;LTE 800;LTE 1800;LTE 2600;GSM
900;GSM 1800;UMTS 2100


>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne



Le 30/04/2015 18:07, Jérôme Amagat a écrit :
> man_made=antenna
> est-ce que man_made est une bonne solution? beaucoup des antenne sont
> sur une tour, un pylône qui lui devrai être tagger en man_made.
> pourquoi pas seulement ajouté antenna=yes sur le support? supprimé
> complètement man_made=antenna ne serai t elle pas une meilleur
> solution pour éviter des confusions?
>
> l'id anfr : il faut voir de quoi on parle. dans le fichier libéré, des
> id il y en a plusieurs : un pour chaque support, station, antenne,
> émetteur et bande. et le "numéro d'identification de l’installation
> sur Cartoradio".
>
> Une autre question : moi je pars du principe que l'on ne peut pas,
> pour un pylône, placer plusieurs points dans osm. j'ai raison?
>
> je repart sur l'exemple que j'ai donner plus haut :
> je verais bien ça :
> man_made=tower (ou autre)
> antenna=yes
> ref:cartoradio=...
> operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM
> "reseau" =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE
> 800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100|
>

La convention sur OSM est de séparer par des ;

Donc plutôt:
operator=RESEAU PRIVE;TDF;SNCF Réseau;FREE MOBILE;IFW;BOUYGUES TELECOM


> utiliser des "|" comme pour les lanes sur les routes permet de donner
> des infos sur chaque operator.
> je ne vois pas comment on pourrait en mettre plus sans rendre le truc
> incompréhensible.
>

Franchement, je ne vois pas l'intérêt de recopier toutes ces données
librement disponibles dans OSM. Inutilement complexe, les mises à jour
manuelles ne seront sûrement jamais faites... mieux vaut se référer à la
source et donc correctement pointer vers elle.
Les ré-utilisateurs potentiels préféreront sûrement reprendre
directement les données de l'ANFR.

-- 
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales

2015-04-30 Par sujet kinju

Je pense que ces adresses 59160 à Lille sont effectivement à Lomme.

2015-04-30 16:30 GMT+02:00 Christian Quest :

>  Sur les 12719 adresses ayant un code postal à 59160, 738 sont à Capinghem
> et les 11981 autres à "Lille"... donc Lomme ?
>
>
>
> Le 30/04/2015 16:07, kinju a écrit :
>
> Est-ce qu'il y a des adresses avec pour code postal 59160 et comme commune
> Capinghem ? Auquel cas peut-être peut-on considéré que lorsque c'est 59160
> Lille, en fait c'est 59160 Lomme, sinon ça peut être Lille ou Capinghem
>
> 2015-04-30 14:52 GMT+02:00 Christian Quest :
>
>>  Dans le fichier BAN, il y a un champ code_insee, un champ code_postal et
>> un champ nom_commune... mais pas de champ "nom_postal".
>>
>> J'ai le même problème avec mon 94210 La Varenne St Hilaire (qui est un
>> nom de quartier de St Maur des Fossés, tout comme Juan les Pins est une
>> partie de la commune d'Antibes).
>>
>> Peux-tu me confirmer que toutes les adresses ayant comme code postal
>> 59160 et comme commune Lille sont à mettre en nom_postal "Lomme" ?
>>
>> Si oui, je ferai un traitement automatique pour remette ça en ordre en
>> ajoutant ce champ proposé côté BANO mais pas encore sur la BAN ODbL...
>>
>>
>>
>> Le 30/04/2015 14:40, kinju a écrit :
>>
>> J'ai constaté qu'ils avaient des soucis pour gérer les communes
>> associées.
>>
>>  Par exemple dans le Nord, la commune de Lomme (59160) est associée à
>> Lille, donc administrativement Lomme n'existe pas.
>>
>>  Sur les sites administratifs (Pôle Emploi, Impôts etc.) lorsque l'on
>> tape "59160" ça propose les villes Lille et Capinghem, mais pas Lomme. Or,
>> d'un point de vue postal, Lomme existe bien.
>>
>>  D'ailleurs certaines rues / places existent à la fois à Lille et à
>> Lomme, donc d'un point de vue purement administratif, il y a deux rue
>> Albert Machin Bidule à Lille.
>>
>> 2015-04-30 9:36 GMT+02:00 Romain MEHUT :
>>
>>>  Bonjour,
>>>
>>>  Voici le lien d'un article intitulé "Sans adresse postale normalisée,
>>> point de très haut débit?" où il est question de la BAN
>>>
>>> http://www.localtis.info/cs/ContentServer?pagename=Localtis/LOCActu/ArticleActualite&cid=1250268831944
>>>
>>>  Romain
>>>
>>>  Le 16 avril 2015 23:17, Christian Quest  a
>>> écrit :
>>>
   Le 16/04/2015 21:54, Frédéric Rodrigo a écrit :

 > - seuls 2 champs ne sont pas proposés en ODbL: le libellé AFNOR et le
 libellé d'acheminement

 Question peut être un peu bête. Mais le libellé AFNOR est calculée, non
 ? Il peut donc être récréé ?


  Il me semble, mais pour OSM ça n'a pas franchement d'intérêt vu que
 c'est finalement une dégradation du nom complet. L'important c'est d'avoir
 un nom correct au départ et ça c'est pas garanti à 100%

 Il va falloir évaluer au plus serré le contenu de la BAN avant de
 reprendre des données pour les insérer dans OSM, tout comme il faut être
 quand même prudent avec les données du cadastre récupérées par BANO.

 --
 Christian Quest - OpenStreetMap France


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


>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>
> --
> Christian Quest - OpenStreetMap France
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

@Amagat, c'est pour le cas où une antenne serait sur un toit ou ailleurs, sans 
support node en dessous. Pour le reste (réussir à placer des infos sur un 
point), je vous laisse débattre, j'ai essayé de trouver le plus optimisé. Sinon 
le id station me parait pas mal comme id.@Lacombe jamais parlé d'antenne à 360, 
j'ai parlé d'une simplification. 


 Le Jeudi 30 avril 2015 18h08, Jérôme Amagat  a 
écrit :
   

 man_made=antennaest-ce que man_made est une bonne solution? beaucoup des 
antenne sont sur une tour, un pylône qui lui devrai être tagger en 
man_made.pourquoi pas seulement ajouté antenna=yes sur le support? supprimé 
complètement man_made=antenna ne serai t elle pas une meilleur solution pour 
éviter des confusions?
l'id anfr : il faut voir de quoi on parle. dans le fichier libéré, des id il y 
en a plusieurs : un pour chaque support, station, antenne, émetteur et bande. 
et le "numéro d'identification de l’installation sur Cartoradio".
Une autre question : moi je pars du principe que l'on ne peut pas, pour un 
pylône, placer plusieurs points dans osm. j'ai raison?
je repart sur l'exemple que j'ai donner plus haut :je verais bien ça 
:man_made=tower (ou autre)antenna=yesref:cartoradio=...operator=RESEAU 
PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM"reseau" =PMR|FM;FH|GSM 
R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE 800;LTE 1800;LTE 2600;GSM 
900;GSM 1800;UMTS 2100|
utiliser des "|" comme pour les lanes sur les routes permet de donner des infos 
sur chaque operator.je ne vois pas comment on pourrait en mettre plus sans 
rendre le truc incompréhensible.
ou alors un truc du genre :operator:1=...reseau 
:1=...antenne:1=...frequence:1=...operator:2=...reseau 
:2=...antenne:2=...frequence:2=..
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Par sujet Jérôme Amagat

man_made=antenna
est-ce que man_made est une bonne solution? beaucoup des antenne sont sur
une tour, un pylône qui lui devrai être tagger en man_made.
pourquoi pas seulement ajouté antenna=yes sur le support? supprimé
complètement man_made=antenna ne serai t elle pas une meilleur solution
pour éviter des confusions?

l'id anfr : il faut voir de quoi on parle. dans le fichier libéré, des id
il y en a plusieurs : un pour chaque support, station, antenne, émetteur et
bande. et le "numéro d'identification de l’installation sur Cartoradio".

Une autre question : moi je pars du principe que l'on ne peut pas, pour un
pylône, placer plusieurs points dans osm. j'ai raison?

je repart sur l'exemple que j'ai donner plus haut :
je verais bien ça :
man_made=tower (ou autre)
antenna=yes
ref:cartoradio=...
operator=RESEAU PRIVE|TDF|SNCF Réseau|FREE MOBILE|IFW|BOUYGUES TELECOM
"reseau" =PMR|FM;FH|GSM R|UMTS 900;UMTS 2100;LTE 2600|BLR 3 GHZ|FH;LTE
800;LTE 1800;LTE 2600;GSM 900;GSM 1800;UMTS 2100|

utiliser des "|" comme pour les lanes sur les routes permet de donner des
infos sur chaque operator.
je ne vois pas comment on pourrait en mettre plus sans rendre le truc
incompréhensible.

ou alors un truc du genre :
operator:1=...
reseau :1=...
antenne:1=...
frequence:1=...
operator:2=...
reseau :2=...
antenne:2=...
frequence:2=...
...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Par sujet Nicolas CORBEL

Bonjour à tous,

2015-04-30 17:02 GMT+02:00 François Lacombe :

>
> Il faut vraiment clarifier l'utilisation d'antenne et de site.
> Installer une antenne qui couvre à 360°, réputée omnidirectionelle, et 3
> antennes couvrant à 120° chacune pour se retrouver au global avec les 360°
> couverts n'est pas la même chose : en 1er il n'y a qu'une cellule, en 2nd
> il y en a 3. La deuxième solution écoule 3 fois plus de trafic que la 1ere.
>

Tout en sachant qu'il est compliqué de savoir si un site couvre ou pas 360°
car on ne connait pas les modèles d'antennes. Un site à 2 secteurs peut
couvrir 2x90° (type TGV) ou 2x180° par exemple selon ce qui est utilisé.


> Nous ne devrions pas considérer les antennes du tout dans nos échanges,
> juste les sites. Donc bannir man_made=antenna.
> Free peut en effet installer une majorité de sites couvrant à 360°, ils
> vont par contre y parvenir en utilisant plusieurs secteurs/antennes de 120°
> pour des questions de capacité de trafic à écouler.
>

Est-ce que se mettre au niveau des "supports" ANFR ne serait pas le plus
simple, en indiquant le propriétaire et les exploitants ?
(éventuellement les technos utilisées, à condition de mettre ça à jour
régulièrement)


> Les données de cartoradio ne doivent pas nous permettre de placer les
> antennes mais uniquement le site radio.
> Cf un site avec des antennes réparties aux coins d'un batiment de grande
> envergure alors que la zone technique avec les équipements est au centre :
> ANFR #368376
>

C'est le soucis oui, la base n'est pas assez précise pour les sites avec
antennes déportées.


Sinon, le soucis d'utiliser les numéros d'identification ANFR, il ne me
semble pas qu'il existe un moyen d'y aller facilement sur Cartoradio
ensuite pour avoir des informations.
Par contre, il est - aujourd'hui - possible de construire une URL pointant
vers cartoradio avec le site au milieu. Mais difficile de savoir si cela
sera encore valable dans 2 ans.

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

Re: [OSM-talk-fr] Normalisation du tag antenne

2015-04-30 Par sujet François Lacombe

Le 30 avril 2015 15:36, dHuy Pierre  a écrit :

> @Lacombe: Pour que vous puissiez pusher vos proposition directement et
> qu'on y travaille de manière collaborative avant de faire naitre un vote
> etc... en plus je souhaiterai le mettre simultanément en anglais et en fr.
>

Les motivations du wiki sont les mêmes.
On peut échanger sur le pad en effet, par contre on va devoir ré-expliquer
nos conclusions à une partie de la communuauté qui prend le wiki comme
référence.
En utilisant les pages de discussions sur les proposition, on garde une
trace tout aussi pérenne et plus centrale.

Les langues sont aussi gérées sur le wiki.
Je ne maitrise que peu le pad, comment ca se passe pour une version
bilingue ?


> @Lacombe (bis): justement j'indique que le tag des infos gsm ne devrait
> pas être fait et le pourquoi de cette idée. J'ai contacté des responsables
> réseaux chez des opérateurs avant de mettre en place ce point justement.
> Les LAC, CID and co ne sont pas cartographiable de manière viable sur osm
> (lien avec une db possible par contre)
>

Ok, +1


> @Amagat @Sibert: justement dans des exemples comme ça on unifie les
> ensembles. Mettons les antennes free couvrent toute à 360 degrés, et
> dispose d'une réseau lte et d'un umts. L'information du coup se fusionne
> sous la forme d'une antenne opérée par free etc... Et du coup 18 antennes
> se transforme en une seule. Il faudrait garder au moins 1 point par
> opérateur et usage (mais du coup je crois avoir mal lu la db car j'avais
> l'impression qu'un support pouvait avoir plusieurs opérateurs)
>

Il faut vraiment clarifier l'utilisation d'antenne et de site.
Installer une antenne qui couvre à 360°, réputée omnidirectionelle, et 3
antennes couvrant à 120° chacune pour se retrouver au global avec les 360°
couverts n'est pas la même chose : en 1er il n'y a qu'une cellule, en 2nd
il y en a 3. La deuxième solution écoule 3 fois plus de trafic que la 1ere.

Nous ne devrions pas considérer les antennes du tout dans nos échanges,
juste les sites. Donc bannir man_made=antenna.
Free peut en effet installer une majorité de sites couvrant à 360°, ils
vont par contre y parvenir en utilisant plusieurs secteurs/antennes de 120°
pour des questions de capacité de trafic à écouler.

Ce ne sont pas des notions triviales, nous devons faire attention à ce que
le modèle qui sera établi soit très précis dans les termes utiliés.

Les données de cartoradio ne doivent pas nous permettre de placer les
antennes mais uniquement le site radio.
Cf un site avec des antennes réparties aux coins d'un batiment de grande
envergure alors que la zone technique avec les équipements est au centre :
ANFR #368376
Les antennes :
Azimut 1 :
https://www.google.fr/maps/place/Rue+Kimmerling,+69003+Lyon/@45.755367,4.86215,3a,23.7y,86.84h,116.86t/data=!3m4!1e1!3m2!1sPlB8T0a5HoFU4U0VHX0RWw!2e0!4m2!3m1!1s0x47f4ea7a3b1f1a0f:0x5ebfb167d782f423
Azimut 2 :
https://www.google.fr/maps/place/Rue+Kimmerling,+69003+Lyon/@45.754476,4.863752,3a,15.2y,8.61h,119.7t/data=!3m4!1e1!3m2!1soT6lM6968aCgjK14qFar6g!2e0!4m2!3m1!1s0x47f4ea7a3b1f1a0f:0x5ebfb167d782f423
Azimut 3 :
https://www.google.fr/maps/place/Rue+Kimmerling,+69003+Lyon/@45.755633,4.86476,3a,15.2y,244.85h,109.48t/data=!3m4!1e1!3m2!1sbLFXt4_RIw2A2rLlz8hFhQ!2e0!4m2!3m1!1s0x47f4ea7a3b1f1a0f:0x5ebfb167d782f423

@Lacombe: les services sont importants au contraire: un répéteur gallileo
> ou gps peut etre utile à connaitre en bord de mer pour la navigation alors
> que si c'est juste antenne radio c'est inutile (voir le use_case). Au pire
> unifier toute la téléphonie.
>

Oui, ce serait bien d'unifier toute la téléphonie parmi la variété de
services radio existants.


> @cquest: l'ID ANFR: effectivement je l'avais oublié j'ai rajouté.
> @cquest: cependant la conservation de données complémentaires peut etre
> pratique, comme
>
> Ce que je veux proposer c'est un tag assez complet pour ne plus avoir à
> l'amender après. Et surtout pas un tag qui ne serve qu'en France!
> J'amende le doc en prenant en compte vos remarques.
>

+1, tout a fait motivé pour y arriver.

A+

François

--
*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales

Sur les 12719 adresses ayant un code postal à 59160, 738 sont à
Capinghem et les 11981 autres à "Lille"... donc Lomme ?


Le 30/04/2015 16:07, kinju a écrit :
> Est-ce qu'il y a des adresses avec pour code postal 59160 et comme
> commune Capinghem ? Auquel cas peut-être peut-on considéré que lorsque
> c'est 59160 Lille, en fait c'est 59160 Lomme, sinon ça peut être Lille
> ou Capinghem
>
> 2015-04-30 14:52 GMT+02:00 Christian Quest  >:
>
> Dans le fichier BAN, il y a un champ code_insee, un champ
> code_postal et un champ nom_commune... mais pas de champ "nom_postal".
>
> J'ai le même problème avec mon 94210 La Varenne St Hilaire (qui
> est un nom de quartier de St Maur des Fossés, tout comme Juan les
> Pins est une partie de la commune d'Antibes).
>
> Peux-tu me confirmer que toutes les adresses ayant comme code
> postal 59160 et comme commune Lille sont à mettre en nom_postal
> "Lomme" ?
>
> Si oui, je ferai un traitement automatique pour remette ça en
> ordre en ajoutant ce champ proposé côté BANO mais pas encore sur
> la BAN ODbL...
>
>
>
> Le 30/04/2015 14:40, kinju a écrit :
>> J'ai constaté qu'ils avaient des soucis pour gérer les communes
>> associées.
>>
>> Par exemple dans le Nord, la commune de Lomme (59160) est
>> associée à Lille, donc administrativement Lomme n'existe pas.
>>
>> Sur les sites administratifs (Pôle Emploi, Impôts etc.) lorsque
>> l'on tape "59160" ça propose les villes Lille et Capinghem, mais
>> pas Lomme. Or, d'un point de vue postal, Lomme existe bien.
>>
>> D'ailleurs certaines rues / places existent à la fois à Lille et
>> à Lomme, donc d'un point de vue purement administratif, il y a
>> deux rue Albert Machin Bidule à Lille.
>>
>> 2015-04-30 9:36 GMT+02:00 Romain MEHUT > >:
>>
>> Bonjour,
>>
>> Voici le lien d'un article intitulé "Sans adresse postale
>> normalisée, point de très haut débit?" où il est question de
>> la BAN
>> 
>> http://www.localtis.info/cs/ContentServer?pagename=Localtis/LOCActu/ArticleActualite&cid=1250268831944
>>
>> Romain
>>
>> Le 16 avril 2015 23:17, Christian Quest
>> mailto:cqu...@openstreetmap.fr>> a
>> écrit :
>>
>> Le 16/04/2015 21:54, Frédéric Rodrigo a écrit :
>>> > - seuls 2 champs ne sont pas proposés en ODbL: le
>>> libellé AFNOR et le libellé d'acheminement
>>>
>>> Question peut être un peu bête. Mais le libellé AFNOR
>>> est calculée, non ? Il peut donc être récréé ?
>>>
>>
>> Il me semble, mais pour OSM ça n'a pas franchement
>> d'intérêt vu que c'est finalement une dégradation du nom
>> complet. L'important c'est d'avoir un nom correct au
>> départ et ça c'est pas garanti à 100%
>>
>> Il va falloir évaluer au plus serré le contenu de la BAN
>> avant de reprendre des données pour les insérer dans OSM,
>> tout comme il faut être quand même prudent avec les
>> données du cadastre récupérées par BANO.
>>
>> -- 
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
> -- 
> Christian Quest - OpenStreetMap France
>
>

-- 
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales

2015-04-30 Par sujet kinju

Est-ce qu'il y a des adresses avec pour code postal 59160 et comme commune
Capinghem ? Auquel cas peut-être peut-on considéré que lorsque c'est 59160
Lille, en fait c'est 59160 Lomme, sinon ça peut être Lille ou Capinghem

2015-04-30 14:52 GMT+02:00 Christian Quest :

>  Dans le fichier BAN, il y a un champ code_insee, un champ code_postal et
> un champ nom_commune... mais pas de champ "nom_postal".
>
> J'ai le même problème avec mon 94210 La Varenne St Hilaire (qui est un nom
> de quartier de St Maur des Fossés, tout comme Juan les Pins est une partie
> de la commune d'Antibes).
>
> Peux-tu me confirmer que toutes les adresses ayant comme code postal 59160
> et comme commune Lille sont à mettre en nom_postal "Lomme" ?
>
> Si oui, je ferai un traitement automatique pour remette ça en ordre en
> ajoutant ce champ proposé côté BANO mais pas encore sur la BAN ODbL...
>
>
>
> Le 30/04/2015 14:40, kinju a écrit :
>
> J'ai constaté qu'ils avaient des soucis pour gérer les communes associées.
>
>  Par exemple dans le Nord, la commune de Lomme (59160) est associée à
> Lille, donc administrativement Lomme n'existe pas.
>
>  Sur les sites administratifs (Pôle Emploi, Impôts etc.) lorsque l'on
> tape "59160" ça propose les villes Lille et Capinghem, mais pas Lomme. Or,
> d'un point de vue postal, Lomme existe bien.
>
>  D'ailleurs certaines rues / places existent à la fois à Lille et à
> Lomme, donc d'un point de vue purement administratif, il y a deux rue
> Albert Machin Bidule à Lille.
>
> 2015-04-30 9:36 GMT+02:00 Romain MEHUT :
>
>>  Bonjour,
>>
>>  Voici le lien d'un article intitulé "Sans adresse postale normalisée,
>> point de très haut débit?" où il est question de la BAN
>>
>> http://www.localtis.info/cs/ContentServer?pagename=Localtis/LOCActu/ArticleActualite&cid=1250268831944
>>
>>  Romain
>>
>>  Le 16 avril 2015 23:17, Christian Quest  a
>> écrit :
>>
>>>   Le 16/04/2015 21:54, Frédéric Rodrigo a écrit :
>>>
>>> > - seuls 2 champs ne sont pas proposés en ODbL: le libellé AFNOR et le
>>> libellé d'acheminement
>>>
>>> Question peut être un peu bête. Mais le libellé AFNOR est calculée, non
>>> ? Il peut donc être récréé ?
>>>
>>>
>>>  Il me semble, mais pour OSM ça n'a pas franchement d'intérêt vu que
>>> c'est finalement une dégradation du nom complet. L'important c'est d'avoir
>>> un nom correct au départ et ça c'est pas garanti à 100%
>>>
>>> Il va falloir évaluer au plus serré le contenu de la BAN avant de
>>> reprendre des données pour les insérer dans OSM, tout comme il faut être
>>> quand même prudent avec les données du cadastre récupérées par BANO.
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>>  ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Normalisation du tag antenne

Merci à tous pour les remarques mais le principe d'un pad est aussi d'ajouter 
vos idées en collaboratif :)
Pour répondre à tous:@marc_sibert: Justement je propose de ne pas taguer la 
station mais bien les antennes pour éviter le sur nombre d'antenne@Thevenon, 
pertinent mais je vois que ça a été ajouté au pad donc nickel@Dumoulin, yep 
bien compris :)@Lacombe: Pour que vous puissiez pusher vos proposition 
directement et qu'on y travaille de manière collaborative avant de faire naitre 
un vote etc... en plus je souhaiterai le mettre simultanément en anglais et en 
fr.@Lacombe (bis): justement j'indique que le tag des infos gsm ne devrait pas 
être fait et le pourquoi de cette idée. J'ai contacté des responsables réseaux 
chez des opérateurs avant de mettre en place ce point justement. Les LAC, CID 
and co ne sont pas cartographiable de manière viable sur osm (lien avec une db 
possible par contre)
@Amagat @Sibert: justement dans des exemples comme ça on unifie les ensembles. 
Mettons les antennes free couvrent toute à 360 degrés, et dispose d'une réseau 
lte et d'un umts. L'information du coup se fusionne sous la forme d'une antenne 
opérée par free etc... Et du coup 18 antennes se transforme en une seule. Il 
faudrait garder au moins 1 point par opérateur et usage (mais du coup je crois 
avoir mal lu la db car j'avais l'impression qu'un support pouvait avoir 
plusieurs opérateurs)@Debeau: si on a l'élevation.@Debeau: Pour info le tag 
made_man=mast n'a JAMAIS été voté donc aussi valable que le mien. Cependant 
pour tous les autres support cette discussion a eu lieu précédemment sur cette 
ML pour les intégrer via osmose.@Lacombe: les services sont importants au 
contraire: un répéteur gallileo ou gps peut etre utile à connaitre en bord de 
mer pour la navigation alors que si c'est juste antenne radio c'est inutile 
(voir le use_case). Au pire unifier toute la téléphonie.
@cquest: l'ID ANFR: effectivement je l'avais oublié j'ai rajouté. @cquest: 
cependant la conservation de données complémentaires peut etre pratique, comme 

Ce que je veux proposer c'est un tag assez complet pour ne plus avoir à 
l'amender après. Et surtout pas un tag qui ne serve qu'en France!J'amende le 
doc en prenant en compte vos remarques.
Librement,
 


 Le Jeudi 30 avril 2015 11h46, Christian Quest  a 
écrit :
   

  
 
 Le 29/04/2015 20:02, Jérôme Amagat a écrit :
  
 
 J'ai pris un exemple dans les données pressentes sur data.gouv.fr de lanfr 
voila ou se trouve le pylone : https://www.openstreetmap.org/node/3487062694
  toutes les donnée sur cette station sont là : 
https://docs.google.com/spreadsheets/d/1Q2I5QfX0imcOyFI2BQlBSA8Y3rM3eVUY9w3EI1gFYXA/edit?usp=sharing
 
  c'est un pylône autostable appartenant à TDF, dessus il y a 8 "supports" 
exploités par différentes personnes ( 3*TDF, SNCF, FREE, Bouygues,...) et sur 
ces "supports" il y a des "antennes", 29 ! en tout sur ce pylône (16 pour 
bouygues, 3 pour free, 2 sncf, 4 TDF, ...) et certaines antennes peuvent 
émettre sur plusieurs fréquences (par exemple pour une antenne free : UMTS 
2100, LTE 2600 et UMTS 900 avec à chaque fois 2 bandes de fréquence). 
  Maintenant comment intégré ça (ou au moins une parti) dans osm? tout ça est 
sur un pylône (d’après la vue aérienne) donc normalement 1 point dans osm, a 
moins d’empiler les nœuds les uns sur les autres. 
   
 Des données métier aussi précises ont elles un réel intérêt dans OSM alors 
qu'elles sont librement accessible ?
 
 Je verrai bien un "résumé" dans OSM qui indique:
 - le pylone,
 - l'usage (GSM, 2/3/4G, autre)
 - les opérateurs...
 - l'ID ANFR pour aller chercher le reste des infos dans une base plus 
détaillée et qui sera sûrement mieux mises à jour qu'OSM !
 
 -- 
Christian Quest - OpenStreetMap France 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales

Dans le fichier BAN, il y a un champ code_insee, un champ code_postal et
un champ nom_commune... mais pas de champ "nom_postal".

J'ai le même problème avec mon 94210 La Varenne St Hilaire (qui est un
nom de quartier de St Maur des Fossés, tout comme Juan les Pins est une
partie de la commune d'Antibes).

Peux-tu me confirmer que toutes les adresses ayant comme code postal
59160 et comme commune Lille sont à mettre en nom_postal "Lomme" ?

Si oui, je ferai un traitement automatique pour remette ça en ordre en
ajoutant ce champ proposé côté BANO mais pas encore sur la BAN ODbL...


Le 30/04/2015 14:40, kinju a écrit :
> J'ai constaté qu'ils avaient des soucis pour gérer les communes
> associées.
>
> Par exemple dans le Nord, la commune de Lomme (59160) est associée à
> Lille, donc administrativement Lomme n'existe pas.
>
> Sur les sites administratifs (Pôle Emploi, Impôts etc.) lorsque l'on
> tape "59160" ça propose les villes Lille et Capinghem, mais pas Lomme.
> Or, d'un point de vue postal, Lomme existe bien.
>
> D'ailleurs certaines rues / places existent à la fois à Lille et à
> Lomme, donc d'un point de vue purement administratif, il y a deux rue
> Albert Machin Bidule à Lille.
>
> 2015-04-30 9:36 GMT+02:00 Romain MEHUT  >:
>
> Bonjour,
>
> Voici le lien d'un article intitulé "Sans adresse postale
> normalisée, point de très haut débit?" où il est question de la BAN
> 
> http://www.localtis.info/cs/ContentServer?pagename=Localtis/LOCActu/ArticleActualite&cid=1250268831944
>
> Romain
>
> Le 16 avril 2015 23:17, Christian Quest  > a écrit :
>
> Le 16/04/2015 21:54, Frédéric Rodrigo a écrit :
>> > - seuls 2 champs ne sont pas proposés en ODbL: le libellé
>> AFNOR et le libellé d'acheminement
>>
>> Question peut être un peu bête. Mais le libellé AFNOR est
>> calculée, non ? Il peut donc être récréé ?
>>
>
> Il me semble, mais pour OSM ça n'a pas franchement d'intérêt
> vu que c'est finalement une dégradation du nom complet.
> L'important c'est d'avoir un nom correct au départ et ça c'est
> pas garanti à 100%
>
> Il va falloir évaluer au plus serré le contenu de la BAN avant
> de reprendre des données pour les insérer dans OSM, tout comme
> il faut être quand même prudent avec les données du cadastre
> récupérées par BANO.
>
> -- 
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales

Les communes associées ça existe aussi administrativement. Sauf pour les
CRÉTINS qui les prennent pour des anciennes communes alors que ce sont
toujours des communes même si elles n'ont plus de conseil municipal
Le 30 avr. 2015 14:42, "kinju"  a écrit :

> J'ai constaté qu'ils avaient des soucis pour gérer les communes associées.
>
> Par exemple dans le Nord, la commune de Lomme (59160) est associée à
> Lille, donc administrativement Lomme n'existe pas.
>
> Sur les sites administratifs (Pôle Emploi, Impôts etc.) lorsque l'on tape
> "59160" ça propose les villes Lille et Capinghem, mais pas Lomme. Or, d'un
> point de vue postal, Lomme existe bien.
>
> D'ailleurs certaines rues / places existent à la fois à Lille et à Lomme,
> donc d'un point de vue purement administratif, il y a deux rue Albert
> Machin Bidule à Lille.
>
> 2015-04-30 9:36 GMT+02:00 Romain MEHUT :
>
>> Bonjour,
>>
>> Voici le lien d'un article intitulé "Sans adresse postale normalisée,
>> point de très haut débit?" où il est question de la BAN
>>
>> http://www.localtis.info/cs/ContentServer?pagename=Localtis/LOCActu/ArticleActualite&cid=1250268831944
>>
>> Romain
>>
>> Le 16 avril 2015 23:17, Christian Quest  a
>> écrit :
>>
>>>  Le 16/04/2015 21:54, Frédéric Rodrigo a écrit :
>>>
>>> > - seuls 2 champs ne sont pas proposés en ODbL: le libellé AFNOR et le
>>> libellé d'acheminement
>>>
>>> Question peut être un peu bête. Mais le libellé AFNOR est calculée, non
>>> ? Il peut donc être récréé ?
>>>
>>>
>>> Il me semble, mais pour OSM ça n'a pas franchement d'intérêt vu que
>>> c'est finalement une dégradation du nom complet. L'important c'est d'avoir
>>> un nom correct au départ et ça c'est pas garanti à 100%
>>>
>>> Il va falloir évaluer au plus serré le contenu de la BAN avant de
>>> reprendre des données pour les insérer dans OSM, tout comme il faut être
>>> quand même prudent avec les données du cadastre récupérées par BANO.
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales

2015-04-30 Par sujet kinju

J'ai constaté qu'ils avaient des soucis pour gérer les communes associées.

Par exemple dans le Nord, la commune de Lomme (59160) est associée à Lille,
donc administrativement Lomme n'existe pas.

Sur les sites administratifs (Pôle Emploi, Impôts etc.) lorsque l'on tape
"59160" ça propose les villes Lille et Capinghem, mais pas Lomme. Or, d'un
point de vue postal, Lomme existe bien.

D'ailleurs certaines rues / places existent à la fois à Lille et à Lomme,
donc d'un point de vue purement administratif, il y a deux rue Albert
Machin Bidule à Lille.

2015-04-30 9:36 GMT+02:00 Romain MEHUT :

> Bonjour,
>
> Voici le lien d'un article intitulé "Sans adresse postale normalisée,
> point de très haut débit?" où il est question de la BAN
>
> http://www.localtis.info/cs/ContentServer?pagename=Localtis/LOCActu/ArticleActualite&cid=1250268831944
>
> Romain
>
> Le 16 avril 2015 23:17, Christian Quest  a écrit
> :
>
>>  Le 16/04/2015 21:54, Frédéric Rodrigo a écrit :
>>
>> > - seuls 2 champs ne sont pas proposés en ODbL: le libellé AFNOR et le
>> libellé d'acheminement
>>
>> Question peut être un peu bête. Mais le libellé AFNOR est calculée, non ?
>> Il peut donc être récréé ?
>>
>>
>> Il me semble, mais pour OSM ça n'a pas franchement d'intérêt vu que c'est
>> finalement une dégradation du nom complet. L'important c'est d'avoir un nom
>> correct au départ et ça c'est pas garanti à 100%
>>
>> Il va falloir évaluer au plus serré le contenu de la BAN avant de
>> reprendre des données pour les insérer dans OSM, tout comme il faut être
>> quand même prudent avec les données du cadastre récupérées par BANO.
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu BANO: visualisation des adresses de la BAN

Oui, j'ai vu ça, mais pas encore trouvé comment gérer ça proprement...

Il n'est pas impossible que je fasse deux couches séparées: une pour
BANO (sans BAN) et une avec juste BAN.


Le 29/04/2015 23:02, Pierre-Yves Berrard a écrit :
> Parfois le rouge pointillé et le rouge de départ se chevauchent,
> rendant le texte carrément illisible.
>
> PY
>
> Le 26 avril 2015 17:20, Christian Quest  > a écrit :
>
> Encore un peu de neuf sur le rendu BANO sur les données BAN...
>
> Afin d'aider à compléter les noms de rues manquants dans OSM, j'ai
> ajouté l'entourage des adresses BAN sur le même principe que celles du
> cadastre.
>
> Pour les différencier, j'ai mis :
> - en pointillé rouge les adresses BAN pour lesquelles un
> rapprochement a
> pu être fait avec FANTOIR mais pas avec OSM
> - en pointillé gris les adresse BAN pour lesquelles le rapprochement
> FANTOIR n'a pas pu être fait.
>
> C'est un premier jet ;)
>
> Exemple sur une commune au cadastre raster:
> http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/48.96311/2.19007
> 
> 
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Normalisation du tag antenne