Re: [OSM-talk-fr] rendu qa : analyse par commune

[didier2020]

Le mardi 26 août 2014 à 08:50 +0200, Pierre-Yves Berrard a écrit : 
> Bonjour, 
> Pourrais-tu donner le descriptif des variables ?
> pY
> 

variable des colonnes:
cog = code insee de la commune
imgvect = si le cadastre est image ou vecteur
region,dept,nom ...
nbca = nombre de carre insee de la commune
popu = somme des valeurs "ind_c" (population) des carre
nbcab = idem nbca mais pour un carre insee n'ayant pas de bati a 100m
popub = idem popu mais pour un carre insee n'ayant pas de bati a 100m
nbcaw = idem nbca mais pour un carre insee n'ayant pas de route a 100m
popuw = idem popu mais pour un carre insee n'ayant pas de route a 100m



> 
> Le 25 août 2014 17:11, didier2020  a écrit :
> bonjour,
> 
> le rendu qa permet de voir les routes et le bati manquant.
> 
> J'ai voulu quantifier cela par commune
> 
> le fichier (3.0Mo) est a cette url :
> http://osm2020.free.fr/qa-commune/
> 
> on peut ainsi trouver
> + des communes ayant un import partiel du cadastre : metz
> (corrigé maintenant),
> nimes
> + avec du bati mais le cadastre au format image :
> Illkirch-Graffenstaden
> (plus de 2 habitant!)
> + une partie des ways manquant (toutes les routes n'ont pas
> nécessairement de la population aux environs).
> 
> le critere de distance entre un carré insee (200*200m) et une
> route ou
> un bati est d'une centaine de metres
> 
> 
> 
> ___
> 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

[OSM-talk-fr] Questions FANTOIR / BANO

[Jean-Christophe Groult]

Bonjour,

En corrigeant les rues de la commune d’Hérouville-st-Clair (14200) je suis
tombé sur plusieurs problèmes que je ne sais pas résoudre.

1er problème : 1 voie = 2 noms = 2 FANTOIR
La D60 qui traverse la commune a longtemps était appelée « route de Lion ».
La mairie l’a renommée en « Avenue du Général de Gaulle » il y a quelques
années, mais le nom d’origine est encore largement utilisé.
Sur le calque Bano, la route de Lion est indiquée manquante, (depuis j’ai
ajouté « Route de Lion » en old_name, mais je ne pense pas que cela change
grand chose).
Le problème est que dans le fichier des références FANTOIR les 2 noms
apparaissent avec chacun sa référence. Donc si j’utilise la référence
FANTOIR de la route de Lion, c’est l'avenue du général de Gaulle qui sera
en erreur.
Est-il possible de mettre 2 références séparées par un point virgule ? La
bonne solution est-elle autre chose ?

1403270910XRTE DE LIONR 0  00
0001987001   001221   LION
1403270678VAV  DU GEN DE GAULLE   R 0  00
0001992309   002021   GAULLE


2ème problème : la numérotation par quartier
Hérouville a un système d’adressage postal original. La numérotation ne se
fait pas par rue mais par quartier. Ce système est en train d’être
remplacer par le modèle classique, mais cela prend du temps.
Par exemple « 10.14 le Bois » est une adresse parfaitement valide : « le
Bois » est le nom du quartier », « 10 » est le numéro de porte (dans le
sens anglais de « gate » pas « door ») et « 14 » est  le numéro d’immeuble
au sein de la porte.
Si on veut « 10 » est le nom de la rue, sauf qu’elle n’a pas d’existence
propre ni dans le cadastre, ni dans FANTOIR.
À la place on a la référence suivante dans FANTOIR:

1403271195GVC  QUARTIER DU BOIS   R 0  00
0001987001   001591   BOIS

Le problème est qu’il n’y a aucune voie qui s’appelle « quartier du bois »
(il y a bien un « boulevard du bois » qui fait le tour du quartier mais il
a son propre n° FANTOIR)
Donc quel est la bonne solution ?
Je mets la référence au niveau de la relation qui définit le quartier ?
(elle n’existe pas encore mais ce n’est pas un problème)
Ou est-ce que je crée une relation associatedStreet avec la liste de toutes
les portes et c’est cette relation qui porte la référence ?
Une autre idée ?


J’ai encore 2 petites questions supplémentaires.
En ajoutant le nom d’une rue composée de plusieurs way, je n’ai mis le nom
que sur la relation associatedStreet et pas sur les way, car je trouvais
cela redondant.
Du coup dans les rendus le nom n’apparait pas du tout.
Est-ce normal ?
Le rendu ne devrait-il pas utiliser les relations quand les way n'ont pas
de nom ?


À l’inverse, de nombreuse pistes cyclables d’Hérouville portent le nom de
la rue qu’elles longent (utile pour le guidage par GPS pour les cyclistes)
mais apparaissent aussi sur la carte en doublon du nom de la rue pour
automobiles.
Considère-t-on cela comme normale ?
ou est-ce qu’il ne faut pas mettre de nom sur les pistes cyclables (un peu
gênant pour les cyclistes) ?
ou est-ce qu’il faut créer une relation associatedStreet qui réunit la rue
et la piste cyclable sous le même nom, ce qui permet de l’enlever de la
piste cyclable ?
ou est-ce au calque de ne pas afficher ce nom ?
une autre solution ?

Merci de m’avoir lu jusqu’au bout :) et merci de toute réponse que vous
pourrez apporter.
LeBret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Questions FANTOIR / BANO

[Pieren]

2014-08-26 11:43 GMT+02:00 Jean-Christophe Groult :

> 1er problème : 1 voie = 2 noms = 2 FANTOIR
> La D60 qui traverse la commune a longtemps était appelée « route de Lion ».
> La mairie l’a renommée en « Avenue du Général de Gaulle » il y a quelques
> années, mais le nom d’origine est encore largement utilisé.
> Sur le calque Bano, la route de Lion est indiquée manquante, (depuis j’ai
> ajouté « Route de Lion » en old_name, mais je ne pense pas que cela change
> grand chose).
> Le problème est que dans le fichier des références FANTOIR les 2 noms
> apparaissent avec chacun sa référence. Donc si j’utilise la référence
> FANTOIR de la route de Lion, c’est l'avenue du général de Gaulle qui sera en
> erreur.
> Est-il possible de mettre 2 références séparées par un point virgule ? La
> bonne solution est-elle autre chose ?


Je n'ai pas examiné les autres points mais sur celui-ci, il faut faire
attention à ne pas ajouter dans OSM des données qui n'existent plus
dans la réalité uniquement pour faire plaisir à l'INSEE. Mettre
l'ancien nom dans "old_name" est la bonne méthode du point de vue
d'OSM. C'est à l'outil de contrôle et de comparaison de tenir compte
de ce tag et il ne faut pas remettre un nom disparu dans un "name",
même séparé par un point-virgule, uniquement pour satisfaire un outil
QA.

Pieren

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

Re: [OSM-talk-fr] Questions FANTOIR / BANO

[Christian Quest]

Le 26 août 2014 11:43, Jean-Christophe Groult  a écrit :

> Bonjour,
>
> En corrigeant les rues de la commune d'Hérouville-st-Clair (14200) je suis
> tombé sur plusieurs problèmes que je ne sais pas résoudre.
>
> 1er problème : 1 voie = 2 noms = 2 FANTOIR
> La D60 qui traverse la commune a longtemps était appelée << route de Lion
> >>. La mairie l'a renommée en << Avenue du Général de Gaulle >> il y a
> quelques années, mais le nom d'origine est encore largement utilisé.
> Sur le calque Bano, la route de Lion est indiquée manquante, (depuis j'ai
> ajouté << Route de Lion >> en old_name, mais je ne pense pas que cela change
> grand chose).
> Le problème est que dans le fichier des références FANTOIR les 2 noms
> apparaissent avec chacun sa référence. Donc si j'utilise la référence
> FANTOIR de la route de Lion, c'est l'avenue du général de Gaulle qui sera
> en erreur.
> Est-il possible de mettre 2 références séparées par un point virgule ? La
> bonne solution est-elle autre chose ?
>
> 1403270910XRTE DE LIONR 0  00
> 0001987001   001221   LION
> 1403270678VAV  DU GEN DE GAULLE   R 0  00
> 0001992309   002021   GAULLE
>


old_name=* est la meilleure option à mon avis.

La pire option est d'ajouter des tags pour compenser un manque côté
logiciel (scripts de rapprochement de BANO par exemple).
Un old_ref:FR:FANTOIR pourrait être envisagé pour décrire ce genre de cas,
c'est à discuter.



> 2ème problème : la numérotation par quartier
> Hérouville a un système d'adressage postal original. La numérotation ne se
> fait pas par rue mais par quartier. Ce système est en train d'être
> remplacer par le modèle classique, mais cela prend du temps.
> Par exemple << 10.14 le Bois >> est une adresse parfaitement valide : << le
> Bois >> est le nom du quartier >>, << 10 >> est le numéro de porte (dans le
> sens anglais de << gate >> pas << door >>) et << 14 >> est  le numéro 
> d'immeuble
> au sein de la porte.
> Si on veut << 10 >> est le nom de la rue, sauf qu'elle n'a pas d'existence
> propre ni dans le cadastre, ni dans FANTOIR.
> À la place on a la référence suivante dans FANTOIR:
>
> 1403271195GVC  QUARTIER DU BOIS   R 0  00
> 0001987001   001591   BOIS
>
> Le problème est qu'il n'y a aucune voie qui s'appelle << quartier du bois >>
> (il y a bien un << boulevard du bois >> qui fait le tour du quartier mais il
> a son propre n° FANTOIR)
> Donc quel est la bonne solution ?
> Je mets la référence au niveau de la relation qui définit le quartier ?
> (elle n'existe pas encore mais ce n'est pas un problème)
> Ou est-ce que je crée une relation associatedStreet avec la liste de
> toutes les portes et c'est cette relation qui porte la référence ?
> Une autre idée ?
>
>
Cas très particulier !

On est plutôt dans le cas d'un lieu-dit, d'une résidence. Ce n'est pas
encore traité par BANO... là aussi ça mérite réflexion et discussion.

En attendant le plus adapté me semble, d'utiliser le addr:place évoqué il y
a peu de temps ici même:
addr:housenumber=10
addr:place=le Bois



> J'ai encore 2 petites questions supplémentaires.
> En ajoutant le nom d'une rue composée de plusieurs way, je n'ai mis le nom
> que sur la relation associatedStreet et pas sur les way, car je trouvais
> cela redondant.
> Du coup dans les rendus le nom n'apparait pas du tout.
> Est-ce normal ?
> Le rendu ne devrait-il pas utiliser les relations quand les way n'ont pas
> de nom ?
>

Les relations associatedStreet permet de lier les adresses à la voirie, pas
à décrire la voirie.
Une description trop relationnelle des données n'est vraiment pas
souhaitable car cela complique énormément leur utilisation.
Met toi de l'autre côté... et tu verra que c'est un casse tête de retrouver
le nom sur les tronçons... il peut même y en avoir plusieurs (rues
limitrophes de communes).



> À l'inverse, de nombreuse pistes cyclables d'Hérouville portent le nom de
> la rue qu'elles longent (utile pour le guidage par GPS pour les cyclistes)
> mais apparaissent aussi sur la carte en doublon du nom de la rue pour
> automobiles.
> Considère-t-on cela comme normale ?
> ou est-ce qu'il ne faut pas mettre de nom sur les pistes cyclables (un peu
> gênant pour les cyclistes) ?
> ou est-ce qu'il faut créer une relation associatedStreet qui réunit la rue
> et la piste cyclable sous le même nom, ce qui permet de l'enlever de la
> piste cyclable ?
> ou est-ce au calque de ne pas afficher ce nom ?
> une autre solution ?
>
>
associatedStreet a été créé à l'origine dans un but d'adressage, pas dans
le but de regrouper les éléments composant une rue (voie principale, contre
allée, pistes cyclables, voies de bus séparées, trottoirs filaires et
surfaciques, etc). En fait, si on modélisait la rue en surfacique tout se
qui se trouve à l'intérieur ferait partie de la rue. Par contre sur les
intersections ça risque d'être un beau challenge !
On 

Re: [OSM-talk-fr] Questions FANTOIR / BANO

[Christophe Merlet]

Le 26/08/2014 13:20, Christian Quest a écrit :
> Le 26 août 2014 11:43, Jean-Christophe Groult  > a écrit :
> 
> Bonjour,
> 
> En corrigeant les rues de la commune d’Hérouville-st-Clair (14200)
> je suis tombé sur plusieurs problèmes que je ne sais pas résoudre.
> 
> 1er problème : 1 voie = 2 noms = 2 FANTOIR
> La D60 qui traverse la commune a longtemps était appelée « route de
> Lion ». La mairie l’a renommée en « Avenue du Général de Gaulle » il
> y a quelques années, mais le nom d’origine est encore largement utilisé.
> Sur le calque Bano, la route de Lion est indiquée manquante, (depuis
> j’ai ajouté « Route de Lion » en old_name, mais je ne pense pas que
> cela change grand chose).
> Le problème est que dans le fichier des références FANTOIR les 2
> noms apparaissent avec chacun sa référence. Donc si j’utilise la
> référence FANTOIR de la route de Lion, c’est l'avenue du général de
> Gaulle qui sera en erreur.
> Est-il possible de mettre 2 références séparées par un point virgule
> ? La bonne solution est-elle autre chose ?
> 
> 1403270910XRTE DE LIONR 0 
> 00 0001987001   001221  
> LION 
> 1403270678VAV  DU GEN DE GAULLE   R 0 
> 00 0001992309   002021  
> GAULLE   
> 
> 
> 
> old_name=* est la meilleure option à mon avis.
> 
> La pire option est d'ajouter des tags pour compenser un manque côté
> logiciel (scripts de rapprochement de BANO par exemple).
> Un old_ref:FR:FANTOIR pourrait être envisagé pour décrire ce genre de
> cas, c'est à discuter.

Est-ce que les codes FANTOIR sont incrémentaux ? Afin de déterminer quel
est l'ancien et le nouveau nom ?


>  
> 
> 2ème problème : la numérotation par quartier
> Hérouville a un système d’adressage postal original. La numérotation
> ne se fait pas par rue mais par quartier. Ce système est en train
> d’être remplacer par le modèle classique, mais cela prend du temps.
> Par exemple « 10.14 le Bois » est une adresse parfaitement valide :
> « le Bois » est le nom du quartier », « 10 » est le numéro de porte
> (dans le sens anglais de « gate » pas « door ») et « 14 » est  le
> numéro d’immeuble au sein de la porte.
> Si on veut « 10 » est le nom de la rue, sauf qu’elle n’a pas
> d’existence propre ni dans le cadastre, ni dans FANTOIR.
> À la place on a la référence suivante dans FANTOIR:
> 
> 1403271195GVC  QUARTIER DU BOIS   R 0 
> 00 0001987001   001591  
> BOIS 
> 
> Le problème est qu’il n’y a aucune voie qui s’appelle « quartier du
> bois » (il y a bien un « boulevard du bois » qui fait le tour du
> quartier mais il a son propre n° FANTOIR)
> Donc quel est la bonne solution ?
> Je mets la référence au niveau de la relation qui définit le
> quartier ? (elle n’existe pas encore mais ce n’est pas un problème)
> Ou est-ce que je crée une relation associatedStreet avec la liste de
> toutes les portes et c’est cette relation qui porte la référence ?
> Une autre idée ?
> 
> 
> Cas très particulier !
> 
> On est plutôt dans le cas d'un lieu-dit, d'une résidence. Ce n'est pas
> encore traité par BANO... là aussi ça mérite réflexion et discussion.
> 
> En attendant le plus adapté me semble, d'utiliser le addr:place évoqué
> il y a peu de temps ici même:
> addr:housenumber=10
> addr:place=le Bois
> 
>  
> 
> J’ai encore 2 petites questions supplémentaires.
> En ajoutant le nom d’une rue composée de plusieurs way, je n’ai mis
> le nom que sur la relation associatedStreet et pas sur les way, car
> je trouvais cela redondant.
> Du coup dans les rendus le nom n’apparait pas du tout.
> Est-ce normal ?
> Le rendu ne devrait-il pas utiliser les relations quand les way
> n'ont pas de nom ?
> 
> 
> Les relations associatedStreet permet de lier les adresses à la voirie,
> pas à décrire la voirie.
> Une description trop relationnelle des données n'est vraiment pas
> souhaitable car cela complique énormément leur utilisation.
> Met toi de l'autre côté... et tu verra que c'est un casse tête de
> retrouver le nom sur les tronçons... il peut même y en avoir plusieurs
> (rues limitrophes de communes).
> 
>  
> 
> À l’inverse, de nombreuse pistes cyclables d’Hérouville portent le
> nom de la rue qu’elles longent (utile pour le guidage par GPS pour
> les cyclistes) mais apparaissent aussi sur la carte en doublon du
> nom de la rue pour automobiles. 
> Considère-t-on cela comme normale ?
> ou est-ce qu’il ne faut pas mettre de nom sur les pistes cyclables
> (un peu gênant pour les cyclistes) ?
> ou est-ce qu’il faut créer une relation associatedStreet qui réunit
> la ru

Re: [OSM-talk-fr] Questions FANTOIR / BANO

[Christian Quest]

Ah si seulement... un exemple au hasard (presque):

1403270910XRTE DE LIONR 0  00
0001987001   001221   LION
1403270678VAV  DU GEN DE GAULLE   R 0  00
0001992309   002021   GAULLE

0910 est devenu 0678 :(

Par contre, FANTOIR contient des informations sur la date d'apparition dans
la base.
Il faudrait plutôt s'orienter je pense sur l'ajout dans FANTOIR
d'informations de regroupement et d'évolution de ce type, une sorte de
colonne "alias" pour indiquer quel est le code FANTOIR actuel qui vient
remplacer cet ancien code toujours actif.
C'est typiquement un truc à mettre en place dans le backend de BANO via le
futur guichet unique !



Le 26 août 2014 13:32, Christophe Merlet  a écrit :

> Le 26/08/2014 13:20, Christian Quest a écrit :
> > Le 26 août 2014 11:43, Jean-Christophe Groult  > > a écrit :
> >
> > Bonjour,
> >
> > En corrigeant les rues de la commune d'Hérouville-st-Clair (14200)
> > je suis tombé sur plusieurs problèmes que je ne sais pas résoudre.
> >
> > 1er problème : 1 voie = 2 noms = 2 FANTOIR
> > La D60 qui traverse la commune a longtemps était appelée << route de
> > Lion >>. La mairie l'a renommée en << Avenue du Général de Gaulle >> il
> > y a quelques années, mais le nom d'origine est encore largement
> utilisé.
> > Sur le calque Bano, la route de Lion est indiquée manquante, (depuis
> > j'ai ajouté << Route de Lion >> en old_name, mais je ne pense pas que
> > cela change grand chose).
> > Le problème est que dans le fichier des références FANTOIR les 2
> > noms apparaissent avec chacun sa référence. Donc si j'utilise la
> > référence FANTOIR de la route de Lion, c'est l'avenue du général de
> > Gaulle qui sera en erreur.
> > Est-il possible de mettre 2 références séparées par un point virgule
> > ? La bonne solution est-elle autre chose ?
> >
> > 1403270910XRTE DE LIONR 0
> > 00 0001987001   001221
> > LION
> > 1403270678VAV  DU GEN DE GAULLE   R 0
> > 00 0001992309   002021
> > GAULLE
> >
> >
> >
> > old_name=* est la meilleure option à mon avis.
> >
> > La pire option est d'ajouter des tags pour compenser un manque côté
> > logiciel (scripts de rapprochement de BANO par exemple).
> > Un old_ref:FR:FANTOIR pourrait être envisagé pour décrire ce genre de
> > cas, c'est à discuter.
>
> Est-ce que les codes FANTOIR sont incrémentaux ? Afin de déterminer quel
> est l'ancien et le nouveau nom ?
>
>
> >
> >
> > 2ème problème : la numérotation par quartier
> > Hérouville a un système d'adressage postal original. La numérotation
> > ne se fait pas par rue mais par quartier. Ce système est en train
> > d'être remplacer par le modèle classique, mais cela prend du temps.
> > Par exemple << 10.14 le Bois >> est une adresse parfaitement valide :
> > << le Bois >> est le nom du quartier >>, << 10 >> est le numéro de porte
> > (dans le sens anglais de << gate >> pas << door >>) et << 14 >> est  le
> > numéro d'immeuble au sein de la porte.
> > Si on veut << 10 >> est le nom de la rue, sauf qu'elle n'a pas
> > d'existence propre ni dans le cadastre, ni dans FANTOIR.
> > À la place on a la référence suivante dans FANTOIR:
> >
> > 1403271195GVC  QUARTIER DU BOIS   R 0
> > 00 0001987001   001591
> > BOIS
> >
> > Le problème est qu'il n'y a aucune voie qui s'appelle << quartier du
> > bois >> (il y a bien un << boulevard du bois >> qui fait le tour du
> > quartier mais il a son propre n° FANTOIR)
> > Donc quel est la bonne solution ?
> > Je mets la référence au niveau de la relation qui définit le
> > quartier ? (elle n'existe pas encore mais ce n'est pas un problème)
> > Ou est-ce que je crée une relation associatedStreet avec la liste de
> > toutes les portes et c'est cette relation qui porte la référence ?
> > Une autre idée ?
> >
> >
> > Cas très particulier !
> >
> > On est plutôt dans le cas d'un lieu-dit, d'une résidence. Ce n'est pas
> > encore traité par BANO... là aussi ça mérite réflexion et discussion.
> >
> > En attendant le plus adapté me semble, d'utiliser le addr:place évoqué
> > il y a peu de temps ici même:
> > addr:housenumber=10
> > addr:place=le Bois
> >
> >
> >
> > J'ai encore 2 petites questions supplémentaires.
> > En ajoutant le nom d'une rue composée de plusieurs way, je n'ai mis
> > le nom que sur la relation associatedStreet et pas sur les way, car
> > je trouvais cela redondant.
> > Du coup dans les rendus le nom n'apparait pas du tout.
> > Est-ce normal ?
> > Le rendu ne devrait-il pas utiliser les relations quand les way
> > n'ont pas de nom ?
> >
> >
> > Les relations associatedStreet permet de lier les a

Re: [OSM-talk-fr] Réunion OSM-Paris de rentrée ! NOUVEAU LIEU

[Marc SIBERT]

OK, j'y serais !


Le 25 août 2014 23:45, Christian Quest  a écrit :

> C'est ce vendredi à partir de 19h et ça se déroulera
>
> Maison des Associations du 2ème arrondissement
> 23, rue Greneta
>
> http://www.openstreetmap.org/node/691721185#map=19/48.86510/2.35053
>
> Connexion réseau et tables seront disponibles pour poser nos ordinateurs
> (portables) et travailler un peu ensemble !
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Questions FANTOIR / BANO

[Jean-Christophe Groult]

Le 26 août 2014 13:32, Christophe Merlet  a écrit :

>
> Le 26/08/2014 13:20, Christian Quest a écrit :
>> > Le 26 août 2014 11:43, Jean-Christophe Groult > > > a écrit :
>> > 1er problème : 1 voie = 2 noms = 2 FANTOIR
>> > La D60 qui traverse la commune a longtemps était appelée « route de
>> > Lion ». La mairie l’a renommée en « Avenue du Général de Gaulle » il
>> > y a quelques années, mais le nom d’origine est encore largement
>> utilisé.
>> > Sur le calque Bano, la route de Lion est indiquée manquante, (depuis
>> > j’ai ajouté « Route de Lion » en old_name, mais je ne pense pas que
>> > cela change grand chose).
>> > Le problème est que dans le fichier des références FANTOIR les 2
>> > noms apparaissent avec chacun sa référence. Donc si j’utilise la
>> > référence FANTOIR de la route de Lion, c’est l'avenue du général de
>> > Gaulle qui sera en erreur.
>> > Est-il possible de mettre 2 références séparées par un point virgule
>> > ? La bonne solution est-elle autre chose ?
>> >
>> > 1403270910XRTE DE LIONR 0
>> > 00 0001987001   001221
>> > LION
>> > 1403270678VAV  DU GEN DE GAULLE   R 0
>> > 00 0001992309   002021
>> > GAULLE
>> >
>> >
>> >
>>
>

> Le 26 août 2014 12:27, Pieren  a écrit :
>> Je n'ai pas examiné les autres points mais sur celui-ci, il faut faire
>> attention à ne pas ajouter dans OSM des données qui n'existent plus
>> dans la réalité uniquement pour faire plaisir à l'INSEE. Mettre
>> l'ancien nom dans "old_name" est la bonne méthode du point de vue
>> d'OSM. C'est à l'outil de contrôle et de comparaison de tenir compte
>> de ce tag et il ne faut pas remettre un nom disparu dans un "name",
>> même séparé par un point-virgule, uniquement pour satisfaire un outil
>> QA.
>>
>> Pieren
>>
>
Le contrôle par old_name peut poser problème. Toujours dans Hérouville, il
y a une place dont le old_name est « Place Saint Clair » et qui a été
renommé « place du 1er décembre 1945 » (son name actuel). Mais depuis une
autre place à 800 m de là a été crée et s’appelle … « Place Saint Clair »
!  Il y a parfois des confusions entre les 2.


>
>> > old_name=* est la meilleure option à mon avis.
>> >
>> > La pire option est d'ajouter des tags pour compenser un manque côté
>> > logiciel (scripts de rapprochement de BANO par exemple).
>> > Un old_ref:FR:FANTOIR pourrait être envisagé pour décrire ce genre de
>> > cas, c'est à discuter.
>>
>>
>>
Je pensais à un ref:FR:FANTOIR=1403270678V;1403270910X
mais je n’ai pas de préférence. C’est juste pour corriger les données.



> > 2ème problème : la numérotation par quartier
>> > Hérouville a un système d’adressage postal original. La numérotation
>> > ne se fait pas par rue mais par quartier. Ce système est en train
>> > d’être remplacer par le modèle classique, mais cela prend du temps.
>> > Par exemple « 10.14 le Bois » est une adresse parfaitement valide :
>> > « le Bois » est le nom du quartier », « 10 » est le numéro de porte
>> > (dans le sens anglais de « gate » pas « door ») et « 14 » est  le
>> > numéro d’immeuble au sein de la porte.
>> > Si on veut « 10 » est le nom de la rue, sauf qu’elle n’a pas
>> > d’existence propre ni dans le cadastre, ni dans FANTOIR.
>> > À la place on a la référence suivante dans FANTOIR:
>> >
>> > 1403271195GVC  QUARTIER DU BOIS   R 0
>> > 00 0001987001   001591
>> > BOIS
>> >
>> > Le problème est qu’il n’y a aucune voie qui s’appelle « quartier du
>> > bois » (il y a bien un « boulevard du bois » qui fait le tour du
>> > quartier mais il a son propre n° FANTOIR)
>> > Donc quel est la bonne solution ?
>> > Je mets la référence au niveau de la relation qui définit le
>> > quartier ? (elle n’existe pas encore mais ce n’est pas un problème)
>> > Ou est-ce que je crée une relation associatedStreet avec la liste de
>> > toutes les portes et c’est cette relation qui porte la référence ?
>> > Une autre idée ?
>> >
>> >
>> > Cas très particulier !
>>
>
Une lubie de l’urbaniste de l’époque. Quand on est du coin, il n’y a pas de
problème, mais les autres peuvent tourner longtemps avant de trouver
l’adresse qu’ils cherchent. D’ailleurs quand je donne rendez-vous dans le
coin, j’envoie carrément un lien sur OSM ;)
La mairie actuelle essaye d’y remédier, mais il y a plus d’une centaine de
rue à individualiser au cadastre et à nommer.


> >
>> > On est plutôt dans le cas d'un lieu-dit, d'une résidence. Ce n'est pas
>> > encore traité par BANO... là aussi ça mérite réflexion et discussion.
>> >
>> > En attendant le plus adapté me semble, d'utiliser le addr:place évoqué
>> > il y a peu de temps ici même:
>> > addr:housenumber=10
>> > addr:place=le Bois
>>
>
Pour le moment je ne mets pas encore les adresses au niveau de chaq

[OSM-talk-fr] Rencontre à Nantes pour la mise à jour des données TAN

[JeanMichel FRANCOIS]

Bonjour !

C'est la rentrée et la TAN (réseau de transport en commun de Nantes) 
vient de publier la mise à jour de son réseau.
Je vous propose d'organiser une rencontre pour effectuer la mise à jour 
du réseau dans OSM.


Lieu: La cantine du numérique
Jour: Des préférences  ?

Les mises à jour annoncée par la TAN :
* C3 plus fréquent
* 66 (nouveau) Ecole Centrale - Audencia < > Babinière
* 12: trajet rallongé
* 90: idem
* 86: trajet modifié (optimisation pour le tram train)
* 96: idem

* 101, 102, ...: carte scolaire revue pour une meilleur compréhension 
(changement de nom)


Il faut en profiter pour mettre à jour le wiki.

Plus d'info:
http://data.nantes.fr/donnees/detail/arrets-horaires-et-circuits-tan/
https://www.tan.fr/jsp/fiche_actualite.jsp?CODE=1407763105596&LANGUE=0&RH=ACCUEIL
http://wiki.openstreetmap.org/wiki/Nantes/Transports_publics

Cordialement,
Jean-Michel

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

Re: [OSM-talk-fr] Questions FANTOIR / BANO

[Pieren]

2014-08-26 16:08 GMT+02:00 Jean-Christophe Groult :

> Le contrôle par old_name peut poser problème. Toujours dans Hérouville, il
> y a une place dont le old_name est « Place Saint Clair » et qui a été renommé
> « place du 1er décembre 1945 » (son name actuel). Mais depuis une autre
> place à 800 m de là a été crée et s’appelle … « Place Saint Clair »  !
> Il y a parfois des confusions entre les 2.

C'est vicieux, ça. Mais je pense que les tags old_name et name font
leur boulot dans ce cas. On peut éventuellement ajouter un tag "note"
décrivant la situation de ces deux places pour éviter que certains
contributeurs ne fasse d'erreur à partir, par exemple, d'une vieille
carte. Ca mange pas de pain.
nb: "Place Saint-Clair" avec tiret, merci de suivre nos règles
toponymiques communes et non les conseils non avisés et isolés de
certain sur cette liste.

> Je suis d’accord que les pistes cyclables n'ont pas vraiment de nom, et je
> suis tenté de l'enlever à celles qui en ont. Mais du coup pour un guidage
> vocale d’un GPS, le cycliste n'a plus d'indication, ce qui est dommage. Pour
> le moment je ne touche à rien.

Un logiciel de guidage devrait pouvoir détecter que la piste cyclable
longe une route et utilise le nom de cette route. Mais pour certains
développeurs, demander à tout le monde de dupliquer le tag "name" est
plus rapide que d'écrire un bon algorithme...

Pieren

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

Re: [OSM-talk-fr] Questions FANTOIR / BANO

[Christian Quest]

Le 26 août 2014 16:08, Jean-Christophe Groult  a écrit :

>
> Le contrôle par old_name peut poser problème. Toujours dans Hérouville, il
> y a une place dont le old_name est << Place Saint Clair >> et qui a été
> renommé << place du 1er décembre 1945 >> (son name actuel). Mais depuis une
> autre place à 800 m de là a été crée et s'appelle ... << Place Saint Clair >>
> !  Il y a parfois des confusions entre les 2.
>


Les c*$s ;)

Ils font un concours à Hérouville ?

Si le script chercher sur name=* avant de se rabattre sur old_name, ça
fonctionnera.



>
>
>>
>>> > old_name=* est la meilleure option à mon avis.
>>> >
>>> > La pire option est d'ajouter des tags pour compenser un manque côté
>>> > logiciel (scripts de rapprochement de BANO par exemple).
>>> > Un old_ref:FR:FANTOIR pourrait être envisagé pour décrire ce genre de
>>> > cas, c'est à discuter.
>>>
>>>
>>>
> Je pensais à un ref:FR:FANTOIR=1403270678V;1403270910X
> mais je n'ai pas de préférence. C'est juste pour corriger les données.
>

Le souci c'est que ça ne nous donne pas d'indication sur le côté obsolète
ou pas... mais bon, c'est une éventualité.



> Une lubie de l'urbaniste de l'époque. Quand on est du coin, il n'y a pas
> de problème, mais les autres peuvent tourner longtemps avant de trouver
> l'adresse qu'ils cherchent. D'ailleurs quand je donne rendez-vous dans le
> coin, j'envoie carrément un lien sur OSM ;)
> La mairie actuelle essaye d'y remédier, mais il y a plus d'une centaine de
> rue à individualiser au cadastre et à nommer.
>


Bien sûr l'urbaniste n'habite pas là... ou alors il ne veut pas que ses
amis viennent le voir ;)



>
>
>>  >
>>> > On est plutôt dans le cas d'un lieu-dit, d'une résidence. Ce n'est pas
>>> > encore traité par BANO... là aussi ça mérite réflexion et discussion.
>>> >
>>> > En attendant le plus adapté me semble, d'utiliser le addr:place évoqué
>>> > il y a peu de temps ici même:
>>> > addr:housenumber=10
>>> > addr:place=le Bois
>>>
>>
> Pour le moment je ne mets pas encore les adresses au niveau de chaque
> bâtiment, j'essaye juste << d'éradiquer des points rouges du rendu BANO >>
> et de voir à quoi rattacher la VC  QUARTIER DU BOIS.
>
>
> http://layers.openstreetmap.fr/?zoom=17&lat=49.21031&lon=-0.3275&layers=BFT
>
>
Oui enfin, pour les cas les plus délicats il vaut mieux laisser du rouge le
temps de trouver une bonne solution.



> Question subsidiaire : le calque Bano est mis à jour tous les combien de
> temps ? Pour le moment je << picore >> les endroits que je connais, mais du
> coup je ne sais plus trop ce qu'il reste à faire
>


C'est encore déclenché de façon manuelle. On devrait passer en automatique
quotidien.


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

Re: [OSM-talk-fr] Questions FANTOIR / BANO

[Jean-Christophe Groult]

Le 26 août 2014 16:50, Christian Quest  a écrit :

>
> Le 26 août 2014 16:08, Jean-Christophe Groult  a
> écrit :
>
>
>> Le contrôle par old_name peut poser problème. Toujours dans Hérouville,
>> il y a une place dont le old_name est « Place Saint Clair » et qui a été
>> renommé « place du 1er décembre 1945 » (son name actuel). Mais depuis une
>> autre place à 800 m de là a été crée et s’appelle … « Place Saint Clair »
>> !  Il y a parfois des confusions entre les 2.
>>
>
>
> Les c*$s ;)
>
> Ils font un concours à Hérouville ?
>
>
On a aussi des rues dont la numérotation des maisons correspond à la
distance en mètre depuis le début de la rue et quelques erreurs de numéros
(des impairs coté pair et réciproquement).
Je vois ça comme une bonne base de tests ;)

Oui enfin, pour les cas les plus délicats il vaut mieux laisser du rouge le
> temps de trouver une bonne solution.
>
>
Ok. Quand une solution sera trouvée, merci de mettre la page wiki à jour,
je ne lis la liste que quand j’ai le temps.


> Un logiciel de guidage devrait pouvoir détecter que la piste cyclable
> longe une route et utilise le nom de cette route. Mais pour certains
> développeurs, demander à tout le monde de dupliquer le tag "name" est
> plus rapide que d'écrire un bon algorithme...

Je vais me faire l’avocat du diable (d’autant que je crois savoir qui a
nommé les pistes cyclables dans ma région, et que effectivement il a
tendance à « simplifier » les données plutôt que complexifier son code).
mais il faut reconnaitre que le guidage se fait souvent sur téléphone
mobile (j’utilise OSMand) et que ces terminaux n’ont pas toujours de grosse
capacité.

Merci à tous pour vos réponses.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] cartopartie Journées du Patrimoine à Goncelin (Isère) 21/09

[Guillaume Allegre]

Pour info,

Les bénévoles "grenoblois" des groupes locaux OSM et Wikimédia interviendront 
en soutien de l'association Le Rif de Goncelin, à la demande d'Agnès Rambaud.

https://wiki.openstreetmap.org/wiki/Grenoble_groupe_local#Journ.C3.A9es_du_Patrimoine_.C3.A0_Goncelin_-_dimanche_21_septembre_2014

Ce sera pour nous la première fois qu'on mènera une animation commune OSM + 
Wikimédia
(Wikipédia et Commons), mais on a déjà plusieurs contributeurs communs, donc 
tout
devrait se passer à merveille ;-)


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] Questions FANTOIR / BANO

[Eric Debeau]

Bonsoir

J'essaie aussi de mettre à jour les infos des noms de rue à Lannion.

Au delà des diverses orthographes existantes (terrain, plan officiel,
Fantoir) pour de nombreuses voies (je pense que je vais devoir rajouter des
alt_name), j'ai aussi rencontré les problèmes suivants :
- vieux noms de rue qui n'existent plus => je vais appliquer la méthode
old_name qui me semble être parfaite
- nom de voie avec des dénominations proches pour 2 codes Fantoir
différents: Rue de Tonquédec et Route de Tonquédec => pas trouvé de règle
et aucune logique (pas d'infos terrain). J'ai fait un choix arbitraire.
- nom de voie correspondant à une place qui est un parking => association
d'un code Fantoir sur la zone représentant le parking => Par exemple, le
parking des Ursulines se confond avec la place des Ursulines => on met le
nom de la place pour le tag name et le nom du parking pour le tag alt-name
?

Merci par avance...Plus que 22 voies à traiter !

Eric


2014-08-26 17:25 GMT+02:00 Jean-Christophe Groult :

>
>
>
> Le 26 août 2014 16:50, Christian Quest  a écrit :
>
>
>> Le 26 août 2014 16:08, Jean-Christophe Groult  a
>> écrit :
>>
>>
>>> Le contrôle par old_name peut poser problème. Toujours dans Hérouville,
>>> il y a une place dont le old_name est « Place Saint Clair » et qui a été
>>> renommé « place du 1er décembre 1945 » (son name actuel). Mais depuis une
>>> autre place à 800 m de là a été crée et s’appelle … « Place Saint Clair »
>>> !  Il y a parfois des confusions entre les 2.
>>>
>>
>>
>> Les c*$s ;)
>>
>> Ils font un concours à Hérouville ?
>>
>>
> On a aussi des rues dont la numérotation des maisons correspond à la
> distance en mètre depuis le début de la rue et quelques erreurs de numéros
> (des impairs coté pair et réciproquement).
> Je vois ça comme une bonne base de tests ;)
>
> Oui enfin, pour les cas les plus délicats il vaut mieux laisser du rouge
>> le temps de trouver une bonne solution.
>>
>>
> Ok. Quand une solution sera trouvée, merci de mettre la page wiki à jour,
> je ne lis la liste que quand j’ai le temps.
>
>
>
> > Un logiciel de guidage devrait pouvoir détecter que la piste cyclable
> > longe une route et utilise le nom de cette route. Mais pour certains
> > développeurs, demander à tout le monde de dupliquer le tag "name" est
> > plus rapide que d'écrire un bon algorithme...
>
> Je vais me faire l’avocat du diable (d’autant que je crois savoir qui a
> nommé les pistes cyclables dans ma région, et que effectivement il a
> tendance à « simplifier » les données plutôt que complexifier son code).
> mais il faut reconnaitre que le guidage se fait souvent sur téléphone
> mobile (j’utilise OSMand) et que ces terminaux n’ont pas toujours de grosse
> capacité.
>
> Merci à tous pour vos réponses.
>
>
> ___
> 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] Questions FANTOIR / BANO

[Jean-Marc Liotier]

On 08/26/2014 09:45 PM, Eric Debeau wrote:
- nom de voie avec des dénominations proches pour 2 codes Fantoir 
différents: Rue de Tonquédec et Route de Tonquédec => pas trouvé de 
règle et aucune logique (pas d'infos terrain). J'ai fait un choix 
arbitraire.


Il n'est pas impossible que tu ais raison, mais il me semble hasardeux 
d'agir sur la simple hypothèse d'une fantaisie de Fantoir... Pas 
d'information sur le terrain, vraiment ?


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

[OSM-talk-fr] Fwd: Quel est le meilleur service pour l'intégration d'orthophoto via josm/merkaartor/id/potlach ?

[Landry Breuil]

Hello,

je suis en train d'intégrer (finalement!!) l'orthophoto 2013 sur l'auvergne
dans nos services WMS & cie, et du coup j'en profite pour sonder un peu le
terrain..

Pour l'instant, le CRAIG fournit uniquement un wms de l'ortho 2009/2010 sur
wms.craig.fr/osm, avec 7/8 projections (EPSG:2154 EPSG:4326 EPSG:3785
EPSG:3857 EPSG:900913 EPSG:4171 EPSG:3945 EPSG:3946), et des couches
distinctes pour 30cm/15cm par agglo. C'est (a mon avis) peu efficace, vu
que c'est un pur WMS non caché.

J'envisage de passer tout par défaut sur du flux caché (avec mapcache ou
mapproxy, a voir, pour l'instant je teste surtout mapcache), avec une seule
couche, mais du coup ca restreint fatalement le nombre de projections
disponibles (je ne ferais que du 3857/GoogleMapCompatible et du 2154) -
pour l'intégration, les outils utilisent forcement que du 3857/900913, avec
les mêmes niveaux de résolutions que les tuiles OSM sur la terre entière je
suppose ?
Je sais que notre WMS est par défaut proposé dans JOSM, que faut il faire
pour modifier la couche/service utilisée ? Qu'est-ce qui est le mieux
supporté par tout les outils, WMTS, TMS ? je vois que merkaartor et josm ne
semblent supporter que WMS/TMS..

Je sais qu'il y'a quelques usages du WMS pour les projections CC45/46 pour
du calage sur le cadastre, donc je ne compte pas fermer le WMS, juste
essayer de pousser 99% des utilisateurs vers un service tuilé pour que ca
soit moins chargé de mon coté, et plus efficace coté utilisateur...

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

Re: [OSM-talk-fr] Fwd: Quel est le meilleur service pour l'intégration d'orthophoto via josm/merkaartor/id/potlach ?

[Christian Quest]

Dans JOSM, on utilisera surtout (uniquement ?) du 3857 ou du CC45/46 quand
on travaille avec le cadastre en même temps ce qui est bien pratique.
Pour le reste je ne vois pas trop le besoin.

WMTS ou TMS ça revient au final à la même chose pour JOSM à ce qu'il me
semble. Le premier a juste une URL à coucher dehors très OGC like comparé
au TMS pur jus ou alors j'ai loupé un truc.



Le 26 août 2014 22:36, Landry Breuil  a écrit :

> Hello,
>
> je suis en train d'intégrer (finalement!!) l'orthophoto 2013 sur
> l'auvergne dans nos services WMS & cie, et du coup j'en profite pour sonder
> un peu le terrain..
>
> Pour l'instant, le CRAIG fournit uniquement un wms de l'ortho 2009/2010
> sur wms.craig.fr/osm, avec 7/8 projections (EPSG:2154 EPSG:4326 EPSG:3785
> EPSG:3857 EPSG:900913 EPSG:4171 EPSG:3945 EPSG:3946), et des couches
> distinctes pour 30cm/15cm par agglo. C'est (a mon avis) peu efficace, vu
> que c'est un pur WMS non caché.
>
> J'envisage de passer tout par défaut sur du flux caché (avec mapcache ou
> mapproxy, a voir, pour l'instant je teste surtout mapcache), avec une seule
> couche, mais du coup ca restreint fatalement le nombre de projections
> disponibles (je ne ferais que du 3857/GoogleMapCompatible et du 2154) -
> pour l'intégration, les outils utilisent forcement que du 3857/900913, avec
> les mêmes niveaux de résolutions que les tuiles OSM sur la terre entière je
> suppose ?
> Je sais que notre WMS est par défaut proposé dans JOSM, que faut il faire
> pour modifier la couche/service utilisée ? Qu'est-ce qui est le mieux
> supporté par tout les outils, WMTS, TMS ? je vois que merkaartor et josm ne
> semblent supporter que WMS/TMS..
>
> Je sais qu'il y'a quelques usages du WMS pour les projections CC45/46 pour
> du calage sur le cadastre, donc je ne compte pas fermer le WMS, juste
> essayer de pousser 99% des utilisateurs vers un service tuilé pour que ca
> soit moins chargé de mon coté, et plus efficace coté utilisateur...
>
> Landry
>
>
> ___
> 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