date:20180104

Je ne comprend quelle erreur puisque j'ai mis un seul n (fondateur de
l'Europe) et non deux (le musicien) comme tu viens de le remettre (en
mettant le fondateur de l'Europe en alt_name avec aussi alt_name:source
pour l'indiquer)
Je pense que le rapprochement avec Jean Monnet à l'extrémité de la rue est
sensé et que c'est le panneau qui a été mal orthographié (et que c'était
correct dans le FANTOIR ou le cadastre: sans doute une erreur dans
l'atelier municipal ou de l'imprimeur, ou de l'agent municipal qui a passé
commande et qui n'a pas été relevée ensuite par l'agent venu le poser ou
une mauvaise transcription dans une archive municipale mal relue)


Le 4 janvier 2018 à 22:04,  a écrit :

> Je ne comprends pas non plus.
>
> Je suis allé voir un autre endroit qui me semble tagué de la même façon.
>
> http://osmose.openstreetmap.fr/fr/map/?item=2060=17;
> lat=46.8011892=1.6681943#zoom=17=48.376827=-4.
> 578563=Mapnik=T=
> 2060=1%2C2%2C3==
>
> Pas d'erreur ou plutôt si :
> *Objet de type FANTOIR non concordant avec un objet OSM*
> Le type FANTOIR numérique est destiné à marquer la voirie
> *node 2045090782 *
> rawedit
> 
> josm
> 
> edit
> 
> *ref:FR:FANTOIR* = 292121800R
> *ref:FR:fantoir* = 1800
>
> Je vois que dans le coin il y a plusieurs adresses en fantoir 1800.
> Pourtant une seule en erreur. Fred, c'est volontaire de ne pas afficher
> les autres ?
>
> Allez jamais 2 sans 3 : sur le Wikipedia et Fantoir, j'ai aussi en Rue
> Robert Schumann. Le test Soundex d'Osmose alerte avec raison.
> Cadastre et panneaux sont d'accord sauf que la rue en question touche une
> Rue Jean Monnet.
> Et donc logiquement ça devrait être Rue Robert Schuman puisque Rue Robert
> Schuman était fondateur de l'Europe communautaire comme Jean Monnet.
> Une Rue Robert Schumann pourquoi pas mais avec Money comme la chanson
> (Schumann avec deux n c'est un musicien).
> Tiens merde depuis, Verdy_p a introduit une erreur car le panneau sur la
> rue c'est bien avec 2 n.
> http://www.openstreetmap.org/way/47939948/history
> Les Pages Jaunes
> 
> comme le SIG de l'agglomération de Lorient en mettent aussi 2.
>
> Il y d'autres Rue Robert Schumann en France (et là peut-être à bon
> escient).
>
> Avec le côté radical de Nominatim, on ne trouve plus la Rue Robert
> Schumann à Guidel.
>
> Donc merci de laisser un alt_name et de vérifier avec d'autres sources. Je
> vais contacter le maire qui s'intéresse à la toponymie.
>
> Jean-Yvon
>
>
> Le 04/01/2018 à 17:56, Cavok - cavok...@free.fr a écrit :
>
> Vous pouvez voir des erreurs par ici
> http://osmose.openstreetmap.fr/fr/map/?item=2060=17;
> lat=46.8011892=1.6681943
>
>
> Le 4 janvier 2018 à 16:18, Cavok  a écrit :
>
>> Il semblerait que cette erreur ne soit reportée que sur les
>> addr:housenumber tagué sur un node et que ceux sur les batiments ne soient
>> pas concernés par cette erreur
>> *... *
>>
>> Le 4 janvier 2018 à 14:51, Cavok  a écrit :
>>
>>> Bonjour, d'importantes erreurs non justifiées sont générées par Osmose
>>> en ce moment:
>>> *Un élément marqué avec “addr:housenumber” ou “addr:housename”, mais
>>> sans autre “addr:street”, “addr:district”, “addr:neighborhood”,
>>> “addr:quarter”, “addr:suburb”, “addr:place” ni “addr:hamlet”, doit être
>>> membre d’une relation “associatedStreet”*
>>> Alors que justement, les relations "associatedStreet" existent.
>>> Trouvez vous également ces erreurs non justifiées.
>>> Merci
>>>
>>
>>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] Imagerie de base dans Id

2018-01-04 Par sujet Donat ROBAUX

Bonsoir,

Je profite du mail de Marc sur les nouveaux pour vous faire part d'une
interrogation à la suite de mes quelques revues de contributions.
Les nouveaux contributeurs contribuent majoritairement avec Id. Outre le
fait de ne pas avoir d'alerte Osmose comme sur Josm (ce qui en soit est
gênant puisque ca laisse passer des erreurs grossières), je m'aperçois que
tous contribuent avec l'imagerie Bing.
Pour faire court, et je pense que vous comprendrez les implications,
peut-on définir pour la France que l'imagerie par défaut est la BDOrtho IGN?

Donat


> -- Message transféré --
> From: marc marc 
> To: talk-fr 
> Cc:
> Bcc:
> Date: Thu, 4 Jan 2018 17:33:35 +
> Subject: Re: [OSM-talk-fr] review_requested=yes sans commentaire pour
> aider les nouveaux
> Bonjour,
>
> je relance le message car je pense que ce serait utile d'aider ceux qui
> se posent des questions sur leur contribution.
> je retourne régulièrement voir ce qu'ils ont fait après mon message,
> ceux qui continue à être actif ont généralement corrigé leurs erreurs.
> le lien affiche les nouveaux qui n'ont eu aucun commentaire.
> > https://resultmaps.neis-one.org/osm-suspicious?country=
> 140=96=10=c=review_
> requested%3Dyes=t=>=10=d=n=t
>
> si on arrive à traiter cette liste de demande d'aide, on peux toujours
> changer le critère pour viser + large.
>
> Cordialement,
> Marc
>
> Le 02. 12. 17 à 14:35, Marc M. a écrit :
> > Bonjour,
> >
> > Le tag permet à un contributeur qu'il souhaite un 2ieme avis sur sa
> modif.
> > Je regarde régulièrement les changeset avec ce tag, le plus souvent
> > utilisé par un contributeur récent.
> > C'est un outil pratique pour aider à s'améliorer.
> > A ma demande, Pascal Neis l'auteur du site web ci-dessous, a ajouté une
> > option pour n'afficher que les changeset sans commentaire, ceux qui sont
> > le + susceptible d'avoir besoin d'un coup d’œil.
> > Pour la France, cela donne
> >> https://resultmaps.neis-one.org/osm-suspicious?country=
> 140=96=-1=review_requested%
> 3Dyes=t=%3E=10=d=n=t#5/46.574/2.878
> >>
> >
> > Cela serait utile qu'on le fasse à plusieurs :)
> > Pour que cette nouvelle option fonctionne, il faut bien sur prendre la
> > peine de mettre un petit mot sur le changeset (même quand il n'y a rien
> > à corriger).
> > Pour ma part, je constate qu'environ la moitié des réactions sont prise
> > en compte (j’imagine que les autres ne sont peut-être pas vu que osm
> > envois uniquement l'info par email, susceptible d'aller en spam, sans
> > notification via le site)
> >
> > Cordialement,
> > Marc
>
>
>


Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

Note: le score de la France est pas bien bon, les meilleurs scores des
opérateurs "grand public" venant d'OVH et Free. Orange et SFR sont encore
loin sur le marché IPv6 du grand public (et des TPE), moins avancés que
Bouygues.

Mais le déploiement d'IPv6 est déjà très avancé en Nouvelle-Calédonie, par
nécessité car il n'y a plus assez d'IPv4 là-bas pour tout le monde et les
performances d'IPv4 se dégradent car cela passe par du NAT obligatoire et
des sessions TCP très instables et un taux de pertes de trames important en
IPv4 via les tunnels. IPv6 rédoud ces problèmes (mais ne résoud pas le
manque cruel de bande passante, autrement dit la lenteur, et le coût des
accès via des connexions sous-marines insuffisantes ou des connexions
satellite très lentes)

En France métropolitaine, on ne manque pas encore d'IPv4, les principaux
opérateurs Internet (qui ont très largement fusionné entre eux et sont
moins nombreux qu'avant, ou qui se sont retirés vers leur pays d'origine,
pour vendre à la place du "roaming") ont de la réserve encore dans leurs
blocs alloués à leur box fixes (même si le RIR européen pousse les
opérateurs à libérer des blocs libres en faisant monter les prix) ! La
demande en IPv4 est forte en premier lieux pour les sites web, mais pour
les mobiles ont commence aussi à avoir des problèmes avec les tunnels peu
performants imposés par les opérateurs (et pas adaptés à la 4G ou la 5G qui
arrive), et les opérateurs français sont tentés en premier lieu de
convertir leurs gros blocs d'IPv4 pour soutenir l'hébergement de sites web
avec des IPv4 fixes.

Comme de plus en plus de gens arrêtent l'ADSL et passent au mobile 4G/5G
(et que la fibre tarde encore à se déployer parce que les opérateurs
gagnent plus à vendre des offres mobiles!), les IPv4 libres sont
nombreuses, pour repartitionner les anciens gros d'IPv4 alloués par les
opérateurs aux box ADSL fixes en France pour les offres d'hébergement et
les clouds et ils le font justement pour que le RIR ne vienne pas leur
réclamer les blocs insuffisamment utilisés.

Et au besoin les mêmes opérateurs ont créé un "marché noir" de relocation
d'adresses IPv4 que le RIR européen ne peut plus (ou ne veut plus) fournir
(sauf à prix prohibitif et pour des blocs petits ou très fragmentés
compliqués à router ou avec des exigences nouvelles que se passent encore
de suivre les gros opérateurs déjà installés).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

2018-01-04 Par sujet François Lacombe

Update: la connexion en http simple ne passe pas chez Orange, je confirme,
même sans JOSM.

Ticket au niveau 3 envoyé
https://twitter.com/InfosReseaux/status/949052812033478656

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 4 janvier 2018 à 23:27, François Lacombe  a
écrit :

> Pour info, même en ayant une connectivité ipv6 native, et en ayant
> prefer.ipv6=true, josm continue de passer par l'ipv4
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> Le 4 janvier 2018 à 23:11, François Lacombe  a
> écrit :
>
>> Hello Vincent, l'API OSM est-il réellement accessible en IPv6 ?
>>
>> Sinon c'est "normal" : il dispose d'entregistrement  dans le DNS.
>> Donc ca va bien passer par l'IPv6, si les abonnés en question disposent
>> d'une dual stack v4/v6
>> Chez Orange c'est en cours de déploiement, tout le monde ne sera pas
>> affecté.
>>
>> Je vais te faire une capture
>>
>> Bonne soirée
>>
>> *François Lacombe*
>>
>> fl dot infosreseaux At gmail dot com
>> www.infos-reseaux.com
>> @InfosReseaux 
>>
>> Le 4 janvier 2018 à 20:02, Vincent Privat  a
>> écrit :
>>
>>> Hello,
>>> Je reçois ces jours-ci par différents canaux de nombreux rapports
>>> d'erreur de JOSM qui ne parvient pas à contacter l'API OSM.
>>> Il semble que le point commun entre tous les gens impactés soit le fait
>>> d'utiliser une connexion ADSL chez Orange.
>>> Le workaround pour ce problème est de positionner à "false" la propriété
>>> "prefer.ipv6" dans les options avancées de JOSM.
>>> Si certains sont concernés et sont prêts à faire des captures réseau
>>> avec wireshark ou équivalent, pour qu'on comprenne mieux le pb, merci de
>>> répondre directement à Dirk Stoecker en se manifestant ici:
>>> https://josm.openstreetmap.de/ticket/15714#comment:10
>>>
>>> A+
>>> Vincent
>>>
>>> ___
>>> 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] Problème IPv6 chez Orange causant des erreurs avec JOSM

IPv6 en ADSL chez Orange n'utilise pas de routage IPv6 natif (contrairement
à la fibre) mais une encapsulation d'une tunnel IPv6 sur IPv4 et il semble
que cela limite la taille des "MTU" aussi bien en TCP qu'en UDP ou raw IP
(ICMP/ping) et que cela pose problème aussi pour HTTPS.

IPv6 sur ADSL chez Orange n'a aucun intérêt, le fournisseur de tunnel IPv6
chez Orange est très peu performant (et surchargé sur ses serveurs pas
adaptés à l'usage haut débit par de nombreux utilisateurs). On peut le
désactiver dans les paramètres de la box Orange (sachant toutefois qu'on
aura du mal à se connecter aux mobiles asiatiques qui ne sont joignables
qu'en IPv6, éventuellement par un tunnel).

Mais je ne constate aucun problème sur la fibre Orange (et je me connecte
très peu aux mobiles IPv6 asiatiques...) et je ne constate pas de problème
même pour visionner une vidéo Youtube en IPv6 natif (il est possible que ce
soit Google lui-même qui fournisse le tunnel IPv6 vers IPv4 si nécessaire
ou qu'il sait détecter corriger les problèmes de MTU trop courtes chez
certains opérateurs).

Orange n'a jamais été clair sur son déploiement IPv6 qui est très en retard
sur le marché, et pas pris en charge correctement sur un certain nombre de
ses box ADSL au firmware obsolète ou sur un certain nombre de ses DSLAMs
(ou collecteurs de trafic régionaux) pas à jour pour faire de l'IPv6 natif
sans tunnel via IPv4 (ou parce qu'il y a des problèmes de compatibilité
avec d'autres opérateurs dont Orange assure la collecte en IP pour ceux qui
ne sont pas "dégroupés" sur leur ligne ADSL).

On peut détecter les problèmes de MTU avec certains fournisseurs de
tunnels, et autres défauts de conenctivité IPv6 avec des outils basés sur
ICMP, ou sur plusieurs sites de test d'IPv6 (dont http://ipv6-test.com/ qui
vous dit si vous avez réellement une connexion IPv6 native).



Le 4 janvier 2018 à 20:02, Vincent Privat  a
écrit :

> Hello,
> Je reçois ces jours-ci par différents canaux de nombreux rapports d'erreur
> de JOSM qui ne parvient pas à contacter l'API OSM.
> Il semble que le point commun entre tous les gens impactés soit le fait
> d'utiliser une connexion ADSL chez Orange.
> Le workaround pour ce problème est de positionner à "false" la propriété
> "prefer.ipv6" dans les options avancées de JOSM.
> Si certains sont concernés et sont prêts à faire des captures réseau avec
> wireshark ou équivalent, pour qu'on comprenne mieux le pb, merci de
> répondre directement à Dirk Stoecker en se manifestant ici:
> https://josm.openstreetmap.de/ticket/15714#comment:10
>
> A+
> Vincent
>
> ___
> 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] Erreur Osmose addr:housenumber

2018-01-04 Par sujet osm . sanspourriel

Bonjour, j'ai compris : curieusement ces adresses ont un code voirie et 
un addr:street.


Et là une personne a vire le addr:housenumber parce que trop près de la 
voirie.


Je ne connaissais pas cette méthode pour les adresses (je savais qu'il y 
en avait au moins 3 mais n'en connaissais que 2.


ça se passe ici :
http://www.openstreetmap.org/changeset/35942339#map=19/48.37727/-4.57861

Jean-Yvon

Le 04/01/2018 à 22:04, Jean-Yvon Landrac a écrit :

*Objet de type FANTOIR non concordant avec un objet OSM*
Le type FANTOIR numérique est destiné à marquer la voirie
*node 2045090782 
* rawedit 
 
josm 
 
edit 
 


*ref:FR:FANTOIR* = 292121800R
*ref:FR:fantoir* = 1800

Je vois que dans le coin il y a plusieurs adresses en fantoir 1800.
Pourtant une seule en erreur. Fred, c'est volontaire de ne pas 
afficher les autres ?



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

Re: [OSM-talk-fr] Montrer dans OSM les toponymes réels dans les différentes langues de la République française

2018-01-04 Par sujet Christian Rogel

Effectivement, je n’avais pas bien saisi la méthode.
C’est intéressant en général et, aussi, dans un but de formation.
En se focalisant sur les éléments de relief et de géographie, d’une part, et 
sur les monuments historiques, cela peut être expliqué dans un atelier sur les 
langues régionales, comme celui qui doit être proposé au SOtM France 2018, à 
Bordeaux..


Christian R.

> Le 4 janv. 2018 à 13:48, marc marc  a écrit :
> 
> Le 04. 01. 18 à 11:59, Christian Rogel a écrit :
>> Le versement préalable des données dans Wikidata serait peu praticable
> 
> je ne saisis pas qu'est-ce qui est peu pratique.
> 
> 1) ajouter les toponymes bretons déjà connu de wikidata mais pas d'osm
> exemple https://overpass-turbo.eu/s/udH
> je prend l'un d'eux
> https://www.openstreetmap.org/node/265650103
> https://www.wikidata.org/wiki/Q682644
> en comparant le nom osm et le nom wikidata fr,
> je peux m'assurer qu'on parle bien de la même chose.
> Puisque c'est le cas, on peux ajouter automatiquement
> name:br="Beg ar Vann" à l'objet osm
> On peux le faire de manière assistée avec josm
> Ou envisager des tests plus systématique à la manière
> d'un module d'import ou d'osmose.
> Après je peux comprendre que c'est peut-être plus motivant/visible pour 
> votre groupe de "recruter" x personnes pour faire le travail à la main 
> plutôt que d'améliorer un programme, surtout que ce ne sont pas les 
> mêmes compétences.
> 
> 2) ajouter des toponymes bretons inconnu tant d'osm que de wikidata
> on ajoute l'info à la main sur wikidata, ce qui nous ramène au cas 
> précédent.
> ou on ajoute l'info à la main sur osm en prévoyant un module pour 
> injecter l'info dans wikidata (histoire d'éviter que le travail doive 
> être fait en double, mais nécessite un programme supplémentaire)


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

Re: [OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

2018-01-04 Par sujet François Lacombe

Pour info, même en ayant une connectivité ipv6 native, et en ayant
prefer.ipv6=true, josm continue de passer par l'ipv4

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 4 janvier 2018 à 23:11, François Lacombe  a
écrit :

> Hello Vincent, l'API OSM est-il réellement accessible en IPv6 ?
>
> Sinon c'est "normal" : il dispose d'entregistrement  dans le DNS.
> Donc ca va bien passer par l'IPv6, si les abonnés en question disposent
> d'une dual stack v4/v6
> Chez Orange c'est en cours de déploiement, tout le monde ne sera pas
> affecté.
>
> Je vais te faire une capture
>
> Bonne soirée
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> Le 4 janvier 2018 à 20:02, Vincent Privat  a
> écrit :
>
>> Hello,
>> Je reçois ces jours-ci par différents canaux de nombreux rapports
>> d'erreur de JOSM qui ne parvient pas à contacter l'API OSM.
>> Il semble que le point commun entre tous les gens impactés soit le fait
>> d'utiliser une connexion ADSL chez Orange.
>> Le workaround pour ce problème est de positionner à "false" la propriété
>> "prefer.ipv6" dans les options avancées de JOSM.
>> Si certains sont concernés et sont prêts à faire des captures réseau avec
>> wireshark ou équivalent, pour qu'on comprenne mieux le pb, merci de
>> répondre directement à Dirk Stoecker en se manifestant ici:
>> https://josm.openstreetmap.de/ticket/15714#comment:10
>>
>> A+
>> Vincent
>>
>> ___
>> 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] Problème IPv6 chez Orange causant des erreurs avec JOSM

2018-01-04 Par sujet François Lacombe

Hello Vincent, l'API OSM est-il réellement accessible en IPv6 ?

Sinon c'est "normal" : il dispose d'entregistrement  dans le DNS.
Donc ca va bien passer par l'IPv6, si les abonnés en question disposent
d'une dual stack v4/v6
Chez Orange c'est en cours de déploiement, tout le monde ne sera pas
affecté.

Je vais te faire une capture

Bonne soirée

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 4 janvier 2018 à 20:02, Vincent Privat  a
écrit :

> Hello,
> Je reçois ces jours-ci par différents canaux de nombreux rapports d'erreur
> de JOSM qui ne parvient pas à contacter l'API OSM.
> Il semble que le point commun entre tous les gens impactés soit le fait
> d'utiliser une connexion ADSL chez Orange.
> Le workaround pour ce problème est de positionner à "false" la propriété
> "prefer.ipv6" dans les options avancées de JOSM.
> Si certains sont concernés et sont prêts à faire des captures réseau avec
> wireshark ou équivalent, pour qu'on comprenne mieux le pb, merci de
> répondre directement à Dirk Stoecker en se manifestant ici:
> https://josm.openstreetmap.de/ticket/15714#comment:10
>
> A+
> Vincent
>
> ___
> 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] Erreur Osmose addr:housenumber

Le 04. 01. 18 à 19:31, Cavok a écrit :
> Vous pouvez voir des erreurs par ici
> http://osmose.openstreetmap.fr/fr/map/?item=2060=17=46.8011892=1.6681943
> 
> Toutes ces erreurs sont apparues le 02 jan 2018, alors que ces contributions
> addr:housenumber date de 2012

il y a un bug général côté osmose ou de sa base de donnée
> https://osmose.openstreetmap.fr/fr/errors/graph.png?source=668=2060=1

j'en ai parlé à Fred et ouvert un ticket
https://github.com/osm-fr/osmose-backend/issues/260
un peu de patience :-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

C'est à Châteauroux qu'on trouve le signalement étrange disant que
"addr:city=Châteauroux" n'est pas concordant avec une ville (sic!).

Là encore il semble qu'Osmose cherche à aligner "addr:city" avec le nom de
la collectivité communale alors que c'est une localité postale. Pendant
longtemps on mettait dans addr:city sur le courier uniquement le nom d'un
bureau distributeur, même s'il couvrait plusieurs communes : la commune
était placée avant le code postal sur une ligne séparée.

Mais cela posait problème avec des adresses à rallonge (il fallait parfois
jongler et manipuler les lignes précédentes pour les abréger et annoter la
commune sur la ligne d'adresse) ; la normalisation du courrier y compris
pour l'international l'a obligé à accepter des formats plus courts (pour ne
pas dépasser les 5 lignes d'adresse, pays compris) où le nom de commune du
bureau distributeur était remplacé par la commune effective sans changer le
code postal lié déjà au bureau distributeur). Ensuite il a été proposé de
préfixer le code postal par le code ISO du pays suivi d'un tiret, mais ça
posait problème dans d'autres pays utilisant des lettres déjà dans leurs
codes postaux: ils voulaient la mention explicite du pays étranger "FRANCE"
sur une ligne séparée du reste de l'adresse franco-française (d'autant plus
qu'il n'y a toujours pas de normalisation internationale des codes postaux
et de leur placement dans les adresses, la France faisant un peu cavalier
seul en mettant le code postal au milieu de l'adresse avant la localité,
alors que les anglo-saxons l'indique en fin d'adresse après la localité...

Pourtant Châteauroux n'est pas le nom d'une commune nouvelle (qui pose
problème pour les adresses postales à cause de la limitation des lignes
d'adresse, tant que les communes nouvelles n'ont pas fusionné leurs listes
de rues pour lever les homonymies).

* Est-ce qu'Osmose voudrait dire que  "addr:city" est ici redondant (car
cela colle avec le nom de la commune où est situé le nom) ?

* Ou bien ne veut-il aucun "addr:city" en France même si c'est nécessaire :
  - pour les adresses physiques dans les communes nouvelles (sachant que
les communes déléguées conservent leur nom légal et que rien n'oblige une
commune nouvelle a revoir leur toponymie de lieux dits ou les noms de rues)
?
  - pour les adresses desservies par le bureau distributeur d'une autre
commune voisine.
  - et dans plein d'endroits où addr:* mentionne en fait une adresse
postale ne correspondant pas au lieu géographique (bien qu'il soit plutôt
recommandé dans ce cas là d'utiliser les sous-clés en "contact:*" plutôt
que celles en "addr:*")

Il me semble que "addr:city" n'a pas vocation à coller à un nom de
collectivité quelconque, c'est juste un toponyme reconnu sans ambiguïté par
la Poste (et aussi par ses résidents dans l'usage commun et qui ne sont pas
près de changer leurs adresses publiées et toutes leurs cartes de visites
ou parutions dans divers annuaires ou connues depuis longtemps à leurs
correspondants qui ne seront que rarement au courant du changement de
collectivité locale qui ne les concerne pas directement).

Et avant que la poste (ou d'autres services postaux ou de livraison) prenne
en compte ces changements, il peut se passer un bon moment (déjà elle va
devoir patienter avec les changements de noms de rues et savoir traiter
encore les anciennes adresses pour acheminer le courrier ou les colis). Ces
adresses peuvent rester également longtemps dans des guides touristiques et
doivent pouvoir être retrouvées avec le nom de l'ancienne commune : un
toponyme survit bien plus longtemps qu'une collectivité qui aura d'autres
occasions encore de changer de périmètre ou de noms.

Une adresse reste une adresse. Ce n'est pas parce qu'une collectivité
décide de change de périmètre ou de nom que les résidents doivent faire des
démarches et modifier leurs enregistrements légaux (fiscalité, registre du
commerce, pièces d'identité, décisions judiciaires, etc.) ou contractuels ;
leur adresse enregistrée reste légale comme adresse indépendamment de la
(ou des) collectivité(s) qui l'a (l'ont) dans son (leur) territoire de
compétence, ces noms restent à la charge des collectivités qui doivent les
conserver comme valides même si ce n'est plus forcément le nom recommandé
pour les nouveaux enregistrements légaux (qui eux n'ont pas la contrainte
de format demandé par la poste pour le traitement automatisé du courrier)

La contrainte de format d'adresse demandée par la poste est devenue un peu
obsolète car l'acheminement se fait très bien avec les codes postaux (et
sinon par un code de substitution visible sur les codes barre orange
surimprimés dans les centres de tri automatiques pour les cas où une
lecture manuelle de l'adresse complète se fera pour préciser
l'acheminement) ; à l'arrivée de toute façon ce code ne sert plus, la
livraison se fait "à vue", et il n'y a plus de contrainte de format autre
que l'usage recommandé des capitales (pour faciliter la lecture des

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

2018-01-04 Par sujet osm . sanspourriel

Je ne comprends pas non plus.

Je suis allé voir un autre endroit qui me semble tagué de la même façon.

http://osmose.openstreetmap.fr/fr/map/?item=2060=17=46.8011892=1.6681943#zoom=17=48.376827=-4.578563=Mapnik=T=2060=1%2C2%2C3==

Pas d'erreur ou plutôt si :

*Objet de type FANTOIR non concordant avec un objet OSM*
Le type FANTOIR numérique est destiné à marquer la voirie
*node 2045090782 *
rawedit

josm

edit

*ref:FR:FANTOIR* = 292121800R
*ref:FR:fantoir* = 1800

Je vois que dans le coin il y a plusieurs adresses en fantoir 1800.
Pourtant une seule en erreur. Fred, c'est volontaire de ne pas afficher
les autres ?

Allez jamais 2 sans 3 : sur le Wikipedia et Fantoir, j'ai aussi en Rue
Robert Schumann. Le test Soundex d'Osmose alerte avec raison.
Cadastre et panneaux sont d'accord sauf que la rue en question touche
une Rue Jean Monnet.
Et donc logiquement ça devrait être Rue Robert Schuman puisque Rue
Robert Schuman était fondateur de l'Europe communautaire comme Jean Monnet.
Une Rue Robert Schumann pourquoi pas mais avec Money comme la chanson
(Schumann avec deux n c'est un musicien).
Tiens merde depuis, Verdy_p a introduit une erreur car le panneau sur la
rue c'est bien avec 2 n.

http://www.openstreetmap.org/way/47939948/history
Les Pages Jaunes

comme le SIG de l'agglomération de Lorient en mettent aussi 2.

Il y d'autres Rue Robert Schumann en France (et là peut-être à bon escient).

Avec le côté radical de Nominatim, on ne trouve plus la Rue Robert
Schumann à Guidel.

Donc merci de laisser un alt_name et de vérifier avec d'autres sources.
Je vais contacter le maire qui s'intéresse à la toponymie.

Jean-Yvon

Le 04/01/2018 à 17:56, Cavok - cavok...@free.fr a écrit :

Vous pouvez voir des erreurs par ici
http://osmose.openstreetmap.fr/fr/map/?item=2060=17=46.8011892=1.6681943

Le 4 janvier 2018 à 16:18, Cavok > a écrit :

Il semblerait que cette erreur ne soit reportée que sur les
addr:housenumber tagué sur un node et que ceux sur les batiments
ne soient pas concernés par cette erreur*...
*

Le 4 janvier 2018 à 14:51, Cavok > a écrit :

Bonjour, d'importantes erreurs non justifiées sont générées
par Osmose en ce moment:
*Un élément marqué avec “addr:housenumber” ou
“addr:housename”, mais sans autre “addr:street”,
“addr:district”, “addr:neighborhood”, “addr:quarter”,
“addr:suburb”, “addr:place” ni “addr:hamlet”, doit être membre
d’une relation “associatedStreet”*
Alors que justement, les relations "associatedStreet" existent.
Trouvez vous également ces erreurs non justifiées.
Merci

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

[OSM-talk-fr] Problème IPv6 chez Orange causant des erreurs avec JOSM

2018-01-04 Par sujet Vincent Privat

Hello,
Je reçois ces jours-ci par différents canaux de nombreux rapports d'erreur
de JOSM qui ne parvient pas à contacter l'API OSM.
Il semble que le point commun entre tous les gens impactés soit le fait
d'utiliser une connexion ADSL chez Orange.
Le workaround pour ce problème est de positionner à "false" la propriété
"prefer.ipv6" dans les options avancées de JOSM.
Si certains sont concernés et sont prêts à faire des captures réseau avec
wireshark ou équivalent, pour qu'on comprenne mieux le pb, merci de
répondre directement à Dirk Stoecker en se manifestant ici:
https://josm.openstreetmap.de/ticket/15714#comment:10

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

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

Vous pouvez voir des erreurs par ici
http://osmose.openstreetmap.fr/fr/map/?item=2060=17=46.8011892=1.6681943

Toutes ces erreurs sont apparues le 02 jan 2018, alors que ces contributions
addr:housenumber date de 2012



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] review_requested=yes sans commentaire pour aider les nouveaux

Bonjour,

je relance le message car je pense que ce serrait utile d'aider ceux qui 
se posent des questions sur leur contribution.
je retourne régulièrement voir ce qu'ils ont fait après mon message,
ceux qui continue à être actif ont généralement corrigé leurs erreurs.
le lien affiche les nouveaux qui n'ont eu aucun commentaire.
> https://resultmaps.neis-one.org/osm-suspicious?country=140=96=10=c=review_requested%3Dyes=t=>=10=d=n=t

si on arrive à traiter cette liste de demande d'aide, on peux toujours 
changer le critère pour viser + large.

Cordialement,
Marc

Le 02. 12. 17 à 14:35, Marc M. a écrit :
> Bonjour,
> 
> Le tag permet à un contributeur qu'il souhaite un 2ieme avis sur sa modif.
> Je regarde régulièrement les changeset avec ce tag, le plus souvent 
> utilisé par un contributeur récent.
> C'est un outil pratique pour aider à s'améliorer.
> A ma demande, Pascal Neis l'auteur du site web ci-dessous, a ajouté une 
> option pour n'afficher que les changeset sans commentaire, ceux qui sont 
> le + susceptible d'avoir besoin d'un coup d’œil.
> Pour la France, cela donne
>> https://resultmaps.neis-one.org/osm-suspicious?country=140=96=-1=review_requested%3Dyes=t=%3E=10=d=n=t#5/46.574/2.878
>>  
>>
> 
> Cela serrait utile qu'on le fasse à plusieurs :)
> Pour que cette nouvelle option fonctionne, il faut bien sur prendre la 
> peine de mettre un petit mot sur le changeset (même quand il n'y a rien 
> à corriger).
> Pour ma part, je constate qu'environ la moitié des réactions sont prise 
> en compte (j’imagine que les autres ne sont peut-être pas vu que osm 
> envois uniquement l'info par email, susceptible d'aller en spam, sans 
> notification via le site)
> 
> Cordialement,
> Marc

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

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

peut-être qu'Osmose n'a pas encore détecté la nouvelle relation
associatedStreet ou le fait que ces adresses y ont été ajoutées plus
récemment. Il peut y avoir un délai mais les notifications Osmose sont
conservées et pas toujours automatiquement annulées si l'analyse suivante
ne détecte plus le problème (dans ce cas on signale "résolu" pour que ce
soit à nouveau vérifié lors de la passe suivante, ou on indique "faux
positif" si le signalement est erroné mais ne doit pas être revérifié : les
objets concernés ne seront vérifiés à nouveau plus tard que s'ils sont
modifiés, par exemple un changement de tags ou un déplacement de noeuds qui
incrémentera leur numéro de version et changera leur date de dernière mise
à jour).

Le 4 janvier 2018 à 14:51, Cavok  a écrit :

> Bonjour, d'importantes erreurs non justifiées sont générées par Osmose en
> ce moment:
> *Un élément marqué avec “addr:housenumber” ou “addr:housename”, mais sans
> autre “addr:street”, “addr:district”, “addr:neighborhood”, “addr:quarter”,
> “addr:suburb”, “addr:place” ni “addr:hamlet”, doit être membre d’une
> relation “associatedStreet”*
> Alors que justement, les relations "associatedStreet" existent.
> Trouvez vous également ces erreurs non justifiées.
> Merci
>
> ___
> 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] Erreur Osmose addr:housenumber

Vous pouvez voir des erreurs par ici
http://osmose.openstreetmap.fr/fr/map/?item=2060=17=46.8011892=1.6681943


Le 4 janvier 2018 à 16:18, Cavok  a écrit :

> Il semblerait que cette erreur ne soit reportée que sur les
> addr:housenumber tagué sur un node et que ceux sur les batiments ne soient
> pas concernés par cette erreur
> *...*
>
> Le 4 janvier 2018 à 14:51, Cavok  a écrit :
>
>> Bonjour, d'importantes erreurs non justifiées sont générées par Osmose en
>> ce moment:
>> *Un élément marqué avec “addr:housenumber” ou “addr:housename”, mais sans
>> autre “addr:street”, “addr:district”, “addr:neighborhood”, “addr:quarter”,
>> “addr:suburb”, “addr:place” ni “addr:hamlet”, doit être membre d’une
>> relation “associatedStreet”*
>> Alors que justement, les relations "associatedStreet" existent.
>> Trouvez vous également ces erreurs non justifiées.
>> Merci
>>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

2018-01-04 Par sujet David Crochet


Bonjour

pour ma part lorsque je rencontre ces erreurs ce sont bien des erreurs.


Cordialement
--

David Crochet


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

Re: [OSM-talk-fr] Montrer dans OSM les toponymes réels dans les différentes langues de la République française

2018-01-04 Par sujet Christian Rogel

> Le 4 janv. 2018 à 12:48, Philippe Verdy  a écrit :
> 
> Déjà standardisés: picard = pcd, normand = nrf, wallon = wa

Merci de l’avoir précisé, mais j’avais mis le code du picard dans la dernière 
version de la liste. 
Pour le moment, nous n’avons en vue pour le serveur OSM France que les 
géolectes de la RF. Les langues romanes de la Suisse seront visibles par le 
débord des cartes (franc-comtois et arpitan)..

> le cas du normand est compliqué par le fait qu'on ne sait pas trop s'il doit 
> unifier aussi le jersias et le guernésiais (officiels dans ces deux 
> territoires).
> le gallo n'est pas codifié effectivement et la seule solution pour l'instant 
> est de le distinguer du français par une extension (provisoire?)

Dans la table des codes ISO 639, il y a un renvoi du jerriais vers la page 
jerriais site Ethnologue. On y voit Also spoken in France, avec renvoi vers la 
fiche du Norman French, 17000 locuteurs, nom alternatif : normand.
Il est clair que nrf signifie norman french.
Ce qui m’étonne, c’est qu’il n’y ait qu’un seul nom en nrf dans OSM et il 
s’agit d’un récif au N de Jersey, les Pierres de Lecq (ou de Lé en normand) ou 
les Paternosters.
Les name:fr-x-norman sont à convertir.

> Le mahorais et les créoles guadeloupéens ou réunionnais ont des codes 
> standards, de même que le tahitien et le wallisien. Regarde l'ISO 639-3.

OK, je n’avais pas pensé au wallisien wls. 28ème géolecte. Le rapport 
Cerquiglini en a trouvé 77 (il manque les langues calédoniennes et guyanaises).

> Attention aux codes d'extension: après "-x-" il ne faut pas plus de 8 
> caractères. De même ces codes d'extension passent toujours après les autres 
> (donc après un éventuel code d'écriture ou de région)

Je supposais bien qu’il y avait une régle de formation.


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

Re: [OSM-talk-fr] Contours des IRIS

Le 04. 01. 18 à 15:00, Philippe Verdy a écrit :
>> J'aimerai connaître :
>> - l'outil que tu vas utiliser pour rapprocher les limites libre
>> imprécise de l'insee des frontières supposée exacte d'osm

> la conflation "à vue de nez"

C'est possible pour faire le premier exemple.
Mais c'est déraisonnable d'envisager du manuel à grand échelle.
Tous les imports/intégrations doivent avoir une partie pour utiliser 
l'existant "en automatique" et pas manuellement pour chaque nœud.
Tu devrais te rapprocher de Vincent pour voir comment il a fait
le rapprochement qu'il a publié sur gouv.fr
Une première étape utile serrait donc d'avoir cette version 
partiellement intégrée à jour.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

Le 04. 01. 18 à 14:51, Cavok a écrit :
> *Un élément marqué avec “addr:housenumber” ou “addr:housename”, mais 
> sans autre “addr:street”, “addr:district”, “addr:neighborhood”, 
> “addr:quarter”, “addr:suburb”, “addr:place” ni “addr:hamlet”, doit être 
> membre d’une relation “associatedStreet”*
> Alors que justement, les relations "associatedStreet" existent.

as-tu un no d'erreur et l'objet osm concerné ?
j'ai constaté qu'osnose est désynro sur certain objets.
cela se voit quand on regarde les tags qu'osmose pense que l'objet a ou 
le nom du dernier contributeur.
je vais ouvrir un ticket
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

2018-01-04 Par sujet Francescu GAROBY

Bonjour,
Tu aurais un exemple à nous montrer, stp ?

Francescu

Le 4 janvier 2018 à 14:51, Cavok  a écrit :

> Bonjour, d'importantes erreurs non justifiées sont générées par Osmose en
> ce moment:
> *Un élément marqué avec “addr:housenumber” ou “addr:housename”, mais sans
> autre “addr:street”, “addr:district”, “addr:neighborhood”, “addr:quarter”,
> “addr:suburb”, “addr:place” ni “addr:hamlet”, doit être membre d’une
> relation “associatedStreet”*
> Alors que justement, les relations "associatedStreet" existent.
> Trouvez vous également ces erreurs non justifiées.
> Merci
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Erreur Osmose addr:housenumber

Il semblerait que cette erreur ne soit reportée que sur les
addr:housenumber tagué sur un node et que ceux sur les batiments ne soient
pas concernés par cette erreur
*...*

Le 4 janvier 2018 à 14:51, Cavok  a écrit :

> Bonjour, d'importantes erreurs non justifiées sont générées par Osmose en
> ce moment:
> *Un élément marqué avec “addr:housenumber” ou “addr:housename”, mais sans
> autre “addr:street”, “addr:district”, “addr:neighborhood”, “addr:quarter”,
> “addr:suburb”, “addr:place” ni “addr:hamlet”, doit être membre d’une
> relation “associatedStreet”*
> Alors que justement, les relations "associatedStreet" existent.
> Trouvez vous également ces erreurs non justifiées.
> Merci
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Contours des IRIS

Le 3 janvier 2018 à 17:18, marc marc  a écrit :

> Le 03. 01. 18 à 16:42, Philippe Verdy a écrit :
>
> > Ce n'est pas si gros que ça.
>
> Il me semble erroné de parler d'intégration.
> On peux pas dire à la fois qu'il y en a des milliers et que tu vas les
> intégrer seul à la main, on parle donc bien d'un import qui devra
> utiliser au maximum les objets actuels.
>
> J'aimerai connaître :
> - l'outil que tu vas utiliser pour rapprocher les limites libre
> imprécise de l'insee des frontières supposée exacte d'osm
> - sur quelle base vas-tu décider où est le tracé exact entre 2 zone iris
> pour la partie du tracé qui ne suis pas une limite existante, par
> exemple lorsqu'il est entre 2 rues.
>

Et comment a-t-on fait pour les cantons qui sont construits sur la base des
IRIS ? On a utilisé des estimations.

Sur les frontières communales on a aussi utilisé (massivement) des
estimations et de la conflation "à vue de nez" parce que même les sources
cadastrles n'étaient pas accordées entre elles (et ne le sont toujours
pas!).
Cela n'a pas bloqué pourtant le projet, mais on a utilisé le fait qi'OSM
est incrémental et permet d'affiner progressivement en fonction de
l'amélioration des sources.

Alors tant pis si un IRIS passe entre deux rues, on utilise le tracé tel
qu'il est, on a juste une ambiguité du point triple exact où nous
raccrocher à d'autres frontières qu'on est sensé "connaitre" mais qui ont
leur propre imprécision aussi.

Franchement je ne vois rien de bloquant: je pense que tu te mets des
barrières initiales supérieures à ce qui est même connu pour l'instant. Si
on suivait cette logique on n'aurait encore en France aucune commune, et
pas plus de départements, régions, arrondissements, et même pas non plus de
frontiètes nationales !

Je pars plutôt du principe qu'on cartographie dans les limites de ce qu'on
connait et que les approximations raisonnables (dans l'état de l'art des
connaissances actuellement disponibles) sont le seul moyen d'avancer et
même inciter ensuite les sources à se mettre d'accord et améliorer leur
précision. Cela se fera avec le temps comme tout le reste dans OSM où on ne
fixe jamais dès le début des exigences trop hautes et inatteignables, et si
on ne fait rien à cause de ça il n'y a aucune chance non plus de voir des
progrès apportés dans le sens qu'on voudrait: c'est parce qu'on
cartographgie ce qu'on connait que les réutilisations apparaissent et font
émerger également de nouveaux besoins. L'Insee ou l'IN font pareil: ils
s'adaptent aux demandes et aux besoins, et procèdent de façon incrémentale.

La cartographie ne sera jamais un projet terminé pour eux comme pour nous,
et que chacun peut aller dans une direction pour montrer les insuffisances
des uns et des autres (on le voit aussi pour la BAN publique contre notre
BANO: cependant ça converge doucement dans la même direction).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Erreur Osmose addr:housenumber

Bonjour, d'importantes erreurs non justifiées sont générées par Osmose en
ce moment:
*Un élément marqué avec “addr:housenumber” ou “addr:housename”, mais sans
autre “addr:street”, “addr:district”, “addr:neighborhood”, “addr:quarter”,
“addr:suburb”, “addr:place” ni “addr:hamlet”, doit être membre d’une
relation “associatedStreet”*
Alors que justement, les relations "associatedStreet" existent.
Trouvez vous également ces erreurs non justifiées.
Merci
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Corse et départements

Disons qu'elle réunit sous le meêm chapeau toutes les compétences locales
dévelues aux conseile départementaux et régionaux. Ce n'est pas si bancale
car ça existe aussi en outre-mer (collectivité unique). La métropole de
Lyon est dans le même cas, même si au plan administratif (national) il y a
eu aussi un changement de frontière des deux sous-préfectures qui existent
toujours mais aucun changement pour la compétence de la préfecture du Rhône
dont le territoire de compétence est maintenant désigné différemment
(puisque le terme "département" est réservé au à la nouvelle collectivité
département du Rhône et plus pour la métropole).

On a deux découpages distincts et parallèles de la France :
- un découpage administratif national (celui de l'Etat représenté par ses
préfectures et sous-préfectures, puis les communes hors communes nouvelles)
- un découpage partiel en collectivités locales (chaque type de
collectivité locale pouvant avoir son propre découpage autonome, y compris
les EPCI ou communes nouvelles qui sont une forme d'organisation des
communes qui leur permet de fusionner la majorité leurs compétences
communales dans une même collectivité locale, mais qui n'effacent pas
totatement ces communes)

Un statut vraiment bancale c'était celui des communes associées, très
difficile à mettre en oeuvre, et sinon le statut particulier des 3 communes
françaises à arrondissements qui ont vraiment chacune leur spécificité (en
plus des statuts locaux des métropoles auxquelles elles participent et qui
ont leur propre découpage différent, comme on le voit dans d'autres
métropoles comme celle de Nantes avec ses pôles de compétence mixtes
intercommunaux/interquartiers indépendant du fonctionnement administratif
des communes)

Soyons clair sur ce que désigne boundary=administrative+admin_level=* :
c'est le découpage national, celui de la déconcentration (de l'Etat
lui-même), et non pas la décentralisation (transferts de compétences de
l'Etat à d'autres collectivités, et droit accordés aux collectivités de se
regrouper pour les gérer en totalité ou en partie, mais elles sont
fortement incitées à se regrouper et dépasser même leurs propres
différences de statuts pour coopérer entre elles ou avec celles de pays
voisins).

Hors, même la déconcentration de l'Etat est de plus en plus compliquée,
elle se fait domaine par domaine, ministère par ministère (ce n'est pas le
même pour l'éducation obligatoire, l'enseignement supérieur, la justice, la
police, l'armée et la défense), voire agence par agence dans un même
ministère (et les ministères changent de domaines et de désignation à
chaque gouvernement tous les 2-3 ans).

boundary=administrative+admin_level=* est donc une vue simplifiée mais ne
traduit pas tout et est de moins en moins pertinent... (à cause de ça on a
du ajouter des admin_type=* ou similaires)



Le 3 janvier 2018 à 11:53, Christian Quest  a
écrit :

> D’apres Wikipedia la CTC est équivalente à une région... mais avec un
> statut un peu différent.
>
> Le mer. 3 janv. 2018 à 10:29, Christian Quest  a
> écrit :
>
>> Encore un status bancal, comme la métropole de Lyon et le département du
>> rhone...
>>
>> Si cette CTC chapeaute le 2A et le 2B, on peut la mettre en admin_level=5
>> comme on a fait pour regrouper 69D et 69M... mais c'est quand même du
>> bricolage administratif tout ça !
>>
>> Le 3 janvier 2018 à 10:17, Francescu GAROBY  a écrit
>> :
>>
>>> Bonjour,
>>> Avant de toucher aux 2 départements corses, j'aimerais qu'on me confirme
>>> une chose : admin_level=6 désigne les départements, ou les conseils
>>> départementaux ? Il me semblait que c'étaient les départements. De même que
>>> admin_level=7 désigne les arrondissements.
>>> Or, les 2 départements corses existent toujours, avec leurs préfectures
>>> respectives. Ce sont les conseils départementaux qui ont disparu au
>>> 01/01/2018, en fusionnant avec la CTC (l'équivalent d'un conseil régional,
>>> pour faire simple).
>>>
>>> Bastia reste donc le chef-lieu du département de Haute-Corse, avec
>>> toujours un préfet, mais plus de conseil départemental.
>>>
>>> Francescu
>>>
>>> Le 2 janvier 2018 à 23:17,  a écrit :
>>>
 Bonjour,

 les départements 2A  et 2B
  sont toujours en
 admin_level=6.

 N'est-ce pas plutôt :
 admin_level=6
 boundary:-2018=administrative
 boundary:2018-=historic
 boundary=historic

 Idem pour Bastia :
 admin_level=8
 admin_level:-2018=6
 admin_level:2018-=8

 (Ajaccio était et reste de niveau 4).

 Je suppose qu'un jour on reverra surgir les plaques d'immatriculation
 20.
 Là La Poste a vu juste en conservant les codes 20xxx.

 Pour la Corse  (et la
 relation) :
 alt_name

Re: [OSM-talk-fr] BANO / Cadastre différence nom de voie

2018-01-04 Par sujet Cyrille37 OSM

Merci ! Je passe donc à l'action :-)

C/.

Le 04/01/2018 à 00:15, Christian Quest a écrit :

Effectivement, bravo Sherlock ! :)

Le 3 janvier 2018 à 21:31, Francois Gouget > a écrit :

On Wed, 3 Jan 2018, Christian Quest wrote:

> Sur le plan cadastral, il y a des libellés qui peuvent être
différents de
> ceux qu'on trouve dans FANTOIR... même si les deux sources sont
la DGFiP.
>
> Là, il n'y a que le terrain qui peut servir à départager ces
incohérences.

Pas tout à fait. Wikipedia est très utile pour pas mal de ces
incohérences. En l'occurrence on découvre que :

* Hongerford est grosso-modo inconnu au bataillon.

* Hungerford est une bourgade Anglaise qui est jumelée avec
Ligueil, la
  ville où ce trouve cette voie !
https://fr.wikipedia.org/wiki/Hungerford

* Et la page anglaise de Ligueil confirme ce jumelage (mais rien
sur la
  page française).
https://en.wikipedia.org/wiki/Ligueil

Donc, indépendamment de ce qui est écrit sur les panneaux, il y a de
très fortes chances qu'Hungerford soit le nom correct.

--
Francois Gouget >
http://fgouget.free.fr/
       Be careful of reading health books, you might die of a
misprint.
                                 -- Mark Twain
___
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

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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

Le 3 janvier 2018 à 23:35,  a écrit :

> Un fond de carte muette (on a) et des fonds par langue ou vectoriels pour
> les textes ça peut être un bon compromis.
>
> Mais le problème n'est pas tant la taille car on peut admettre que les
> principales langues ont des communautés assez grandes pour avoir un serveur
> de tuile (comme OSM-FR et OSM-DE) l'ont. Que le serveur de la fondation qui
> sert les tuiles depuis la France soit en langue locale ou en FR si
> possible, ça ne change pas grand chose en terme de bande passante.
>
Ce n'est pas tant un problème de bande passante que de génération des
tuiles et  leur stockage.

Le fond de carte vide OK, c'est indépendant des langues à condition de ne
pas y mettre les icones qui ont la même emprise que les libellés.
Pour les libellés et icônes rien ne vaut le vectoriel (mais compliqué de
gérer le placement et la densité, et encore plus si on veut des libellés le
long de courbes (noms de rivières et frontières), car là pour l'instant je
n'ai pas encore vu de rendu vectoriel capable de le faire correctement en
javascript.

Les tuiles vectorielles existent (au format MBTile de MapBox) mais ça
demande un framework javascript conséquent et pas facile à régler (sachant
que le moteur javascript ne sait pas au départ quelles polices il va
réellement utiliser et qu'il va devoir faire des mesures en fonction du
rendu final et de divers paramètres utilisateur comme la résolution réelle,
et que le lissage des caractères avec ClearType ou similaire et le "font
hinting" joue aussi sur la taille et la lisibilité finale; si on y arrive,
ensuite des praramètres de préférence utilisateur vont entrer en jeu comme
le niveau de zoom spécifique au texte, et que cela risque de ne pas être
cohérent non plus avec la taille des icones qui sont dans d'autres formats
bitmap ou SVG utilisant des mesures différentes, ou alors un intègre au
moteur des polices SVG et on met toutes les icones en SVG, car il est
diffiicile de faire cohabiter les moteurs de rendu de texte standards du
navigateur avec un moteur de rendu Javascript/WebGL, sur la base d'un
Canevas HTML5, prenant en charge facilement le SVG : les formats
TrueType/OpenType et polices bitmaps dans divers format et différentes
capacités d'ajustement ou de métriques selon la plateforme compliquent pas
mal les choses, même avec WebGL et HTML5 ce n'est pas simple).

Enfin WebGL c'est bien sur le papier mais ça demande des navigateurs
compatibles (ce n'est pas le cas de tous les smartphones et les diférences
entre OS mobiles sont encore très importantes). Le rendu bitmap est pour
l'instant celui qui offre le plus de compatibilité, mais il est
effectivemetn très couteux sur les serveurs. La solution utilisée en
général poru les mobiles est le développement d'une "app" mobile spécifique
(mais ensuite déploiement sur GooglePlay, ApplyStore ou Windows Store et on
oublie certains smartphones bon marchés sur d'autres OS mobiles qu'Android,
iOS et Windows, et aussi pas mal d'anciennes versions de ces OS qui
changent sans arrêt leurs APIs !)

On aimerait HTML5 disponible partout avec un bon moteur Javascript
performant et le support alors de WebGL mais ce n'est pas encore le cas.
Certes cela progresse et si on parle ici de la France, ce ne devrait plus
être un problème de passer au tout HTML5, quitte à proposer comme solution
de repli le rendu bitmap Mapnik (cartoCSS d'OSM.org ou les deux rendus
d'OSM.fr: générique et HOT, ou CycleMap et TransportMap, ou encore le rendu
allemand).

Mais il serait temps qu'OSM songe à finalement déployer un moteur WebGL
utilisant les MBTiles et le proposer directement sur son site (et avec des
mises à jour plus fréquentes et plus complètes en terme de tags supportés
que ceux de MapCat proposé juste à titre de démo, et sans non plus devoir
utiliser un abonnement chez MapBox pour avoir accès à ses très riches
palettes de styles).

Ensuite on reparlera du rendu 3D toujours en chantier et où opn n'a pas
grand chose à proposer qui soit disponible pour tous.

OSM France songe-t-il développer un rendu vectoriel libre à base de MBTiles
?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Montrer dans OSM les toponymes réels dans les différentes langues de la République française

Le 04. 01. 18 à 11:59, Christian Rogel a écrit :
> Le versement préalable des données dans Wikidata serait peu praticable

je ne saisis pas qu'est-ce qui est peu pratique.

1) ajouter les toponymes bretons déjà connu de wikidata mais pas d'osm
exemple https://overpass-turbo.eu/s/udH
je prend l'un d'eux
https://www.openstreetmap.org/node/265650103
https://www.wikidata.org/wiki/Q682644
en comparant le nom osm et le nom wikidata fr,
je peux m'assurer qu'on parle bien de la même chose.
Puisque c'est le cas, on peux ajouter automatiquement
name:br="Beg ar Vann" à l'objet osm
On peux le faire de manière assistée avec josm
Ou envisager des tests plus systématique à la manière
d'un module d'import ou d'osmose.
Après je peux comprendre que c'est peut-être plus motivant/visible pour 
votre groupe de "recruter" x personnes pour faire le travail à la main 
plutôt que d'améliorer un programme, surtout que ce ne sont pas les 
mêmes compétences.

2) ajouter des toponymes bretons inconnu tant d'osm que de wikidata
on ajoute l'info à la main sur wikidata, ce qui nous ramène au cas 
précédent.
ou on ajoute l'info à la main sur osm en prévoyant un module pour 
injecter l'info dans wikidata (histoire d'éviter que le travail doive 
être fait en double, mais nécessite un programme supplémentaire)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Montrer dans OSM les toponymes réels dans les différentes langues de la République française