Re: [OSM-talk-fr] Défusion de commune

2019-12-31 Par sujet Donat ROBAUX 
Ca y est c'est fait. Vous m'excuserez de l'avoir fait en 3 changeset, mais je
voulais faire ca propre:
https://www.openstreetmap.org/changeset/79071173
https://www.openstreetmap.org/changeset/79071176
https://www.openstreetmap.org/changeset/79071178

Vous avez le droit de jeter un œil pour voir si c'est bien fait. Pour
l'ancienne "commune nouvelle", à voir si on laisse comme ca ou pas. La
situation est peu fréquente. Je ne sais pas ce qui a été fait pour les
autres cas qui se sont présentés.

On va pouvoir faire un tweet en disant qu'on est les seuls à jour!

Donat



--
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] Défusion de commune

2019-12-31 Par sujet Philippe Verdy 
La date c'est surtout pour les élections municipales, il fallait que ce
soit fait avant la clôture des listes électorales (espérons que les
inscriptions de dernière minute ou cette année aient bien précisé la
commune d'inscription, sinon il va y avoir un peu du boulot en janvier pour
réviser en tenant compte des adresses des nouveaux inscrits, avant l'envoi
des cartes d'électeurs en fin janvier ou début février, au moins 1 mois
avant le scrutin et pour les dépôts de candidatures). Les listes ne peuvent
normalement plus être touchées le 1er janvier. Ces derniers jours depuis
l'arrêté qu'elles ont du recevoir en urgence, la commune a du s'atteler à
contrôler ça mais elles ont un mois pour finaliser leurs listes et les
faire certifier et déposer en préfecture.

Le mar. 31 déc. 2019 à 20:48, Donat ROBAUX  a écrit :

> Hello,
>
> J'ai bien fait de regarder le 20h de TF1. Il est question de la défusion de
> commune de Saline (14). Donc chaque commune repart chez soi: Troarn et
> Sannerville au 1er janvier.
>
> Le 28 décembre, le tribunal administratif de Caen a annulé l’arrêté
> préfectoral portant sur la création de la commune nouvelle de Saline, à
> compter du 31 décembre 2019 (pour que les décisions prises depuis la fusion
> ne soient pas caduques). À cette date, Sannerville et Troarn redeviendront
> deux communes distinctes.
>
> Donat
>
>
>
> --
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Défusion de commune

2019-12-31 Par sujet osm . sanspourriel 
Excuse valable. Tu fais les changements idoines dans 2 h ?
Bonne année deux mille vins... à ne pas prendre à la lettre mais à consommer 
avec modération


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

[OSM-talk-fr] Défusion de commune

2019-12-31 Par sujet Donat ROBAUX 
Hello,

J'ai bien fait de regarder le 20h de TF1. Il est question de la défusion de
commune de Saline (14). Donc chaque commune repart chez soi: Troarn et
Sannerville au 1er janvier.

Le 28 décembre, le tribunal administratif de Caen a annulé l’arrêté
préfectoral portant sur la création de la commune nouvelle de Saline, à
compter du 31 décembre 2019 (pour que les décisions prises depuis la fusion
ne soient pas caduques). À cette date, Sannerville et Troarn redeviendront
deux communes distinctes.

Donat



--
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] absence de BAN dans BANO

2019-12-31 Par sujet deuzeffe 

Le 31/12/2019 à 16:09, Vincent de Château-Thierry a écrit :


il n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2
:)


\o/


oui yapluka, un sujet pour le début de l'année :)


C'était bien pour préparer le terrain, dans cette optique, que toi et 
tes acolytes (dont les noms m'échappent pour l'heure - ybon ?) avez 
relancé un osm-vs-fantoir digne de la 3e décennie du 3e millénaire, non 
? Ou alors osm-vs-fantoir=BANOv2 ?


--
deuzeffe, qui s'y perd.

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

Re: [OSM-talk-fr] absence de BAN dans BANO

2019-12-31 Par sujet Philippe Verdy 
Les données LO/OL sont programmées pour s'éteindre ? N'est-ce pas l'OdBL
qui rassemble tout le monde à terme?
Et l'ODbL de toute façon impose l'attribution, comme la licence LO/OL, je
ne vois pas ce que ça change (pour que ce soit clair et ne pas avoir à
l'indiquer sur des tonnes d'objets)

Les fournisseurs libres les plus fréquents sont mentionnés sur la page de
copyright d'OSM, de sorte qu'il n'est plus nécessaire de mentionner ces
sources dans les données OSM elles-mêmes.

Et ces sources restent encore dans les tags sources des changesets, surtout
les sources d'imagerie (où on peut aussi les dater, surtout pour les
besoins de maintenance ultérieure, histoire de savoir quel jeu historique
de données a été utilisé et si une mise à jour ultérieure de la source ne
devrait pas les modifier, ça sert à avoir une idée de la fraicheur des
données pour les tags individuels; sinon chaque objet OSM a une date de
version, mais cela ne trace pas la date de la source, ce peut être
n'importe quelle correction secondaire, comme un recalage, une scission de
noeud, faire un peu de place pour poser plus précisément d'autres objets à
côté, pas mal de modifs étant faites pour être plus précises
géométriquement que la source d'origine qui ne visait pas les objets
voisins; des tas de modifs étant nécessaire pour le travail de fusion et
préparation des autres données ajoutées; d'autres modifs sont des
traductions ajoutées librement ne venant pas des sources monolingues
d'origine, donc la date des objets OSM n'est pas toujours le bon indicateur
de la fraicheur de la source utilisée).

Le mar. 31 déc. 2019 à 16:50, marc marc  a
écrit :

> Le 31.12.19 à 15:51, Christian Quest a écrit :
> > la BAN sera dispo "avant la fin de l'année" sous Licence Ouverte, donc
> > compatible avec l'ODbL d'OSM et de BANO.
>
> je n'ai pourtant pas encore commencé le réveillon.
> mais depuis quand l'obligation d'attribution de la LO est compatible
> avec l'absence d'attribution des sources contribuant à osm ?
> si j'affiche la carte d'un changeset provenant d'une source LO,
> il y a pas d'attribution "donnée venant de cette source LO"
> c'est pour cela qu'il me semblait qu'on devait se farcir
> des demandes d'exeption pour que la source accepte de renoncer
> à l'attribution et se contente d'être mentionné dans les sources
> contribuant à osm
>
> Je suis en tout cas ravi si la BANOv2 ou v3 (surtout ses outils
> à la contribution osm) incluera la BAN en dernier resort.
> ___
> 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] SPAM, Re: Problème avec ID - besoin d'aide

2019-12-31 Par sujet Philippe Verdy 
Voilà comment une spécif est devenue illisible et c'est à moi qu'on vient
dire que supprimer les espaces non nécessaires serait illisible?
Il y a trop de règles ici, le "fallback" (||) ne sert à rien et complique
inutilement, la syntaxe indiquée n'étant même pas correctement spécifiée en
terme d'associativité.
Et je ne vois pas du tout pourquoi deux règles "Mo 08:00-12:00;Mo
14:00-18:00" sont fausses (même si ici c'est évidemment équivalent à une
seule règle combinée/factorisée "Mo 08:00-12:00,14:00-18:00 en utilisant la
virgule simplement comme séparateur secondaire entre deux horaires des
mêmes dates, ou entre deux dates au même horaire).
la présence ou pas du qualificateur final "off" ne devrait strictement rien
changer à l'associativité.

Et puis cette "doc" ne suit même pas tous les usages de l'outil de test que
tu utilises, il y a d'autres outils mais franchement cette page de doc est
très orientée selon une définition à priori non testée et qui ne fonctionne
pas telle quelle et n'a en fait été suivi exactement par /personne/.

"opening_hours" est conçu n'importe comment, pas pour être lisible, et
plein d'ambiguités comme sa doc. chacun y a mis sa sauce sans vérifier
comment les autres utilisaient ou analysaient le reste.

C'est tellement plus simple (même pour un lecteur humain) de concevoir un
traitement cumulatif et un traitement ordonné des règles. Ensuite on peut
discuter de la façon de scinder les horaires sur plusieurs tags numérotés
(c'est simpel de voir où on peut couper: partout où un point-virgule est
admis, mais il faut une règle d'ordre donc une convention de nommage pour
le numéro dans la clé). Pas besoin de base externe avec une URL qui ne sera
jamais traitée (et qui ne sert à rien: autant utiliser website=* pour le
site officiel mentionnant sur sa page d'info les horaires, et qu'on
visitera alors dans un navigateur); ce ne sera jamais plusieurs dizaines de
kilooctets comem pour toute une page web avec son HTML, ses styles, ses
images, ses scripts, ses publicités et traqueurs web et autres formulaires.
et toute la déco et l'animation voire le son et la vidéo qui vont avec ou
des éléments "dangereux/malveillants", sinon intrusifs (boutons sociaux,
Google Sense, vendeurs en ligne, etc) et qui vous suivent ensuite partout
où vous allez sur le web et permettent à des tiers de faire du
rapprochemetn de donénes massif.

Qui utilise le "fallback" (||), qui ne sert à rien? On peut faire bien plus
simple sans lui. Deux séparateurs de règles (un majeur ";" et un mineur ","
suffisent à tout et ça ne cause aucune difficulté d'interprétation aussi
bien pour un robot et c'est le maximum compréhensible par un humain).



Le mar. 31 déc. 2019 à 14:49, Jérôme Seigneuret 
a écrit :

> C'est un truc de fou quand même d'être aussi têtu!
> Tu me parles du comportement du mot clé *off. *Ca n'a rien à avoir avec
> ce que je mentionne!
>
> Pour rappel ta proposition c'est ça à la base
> *Mo-Fr 11:45-14:00,17:00-20:00;*
> *We 11:30-11:45; < ici tu n'ajoutes pas un horaire mais tu le respécifies
> pour le jour en question*
> *Mo 11:45-12:00 off; < là ok*
> *We 13:00-14:00,18:00-20:00 off;< le off ne sert à rien mercredi a été
> redéfini uniquement de 11h30 à 11h45*
> *Tu 20:00-21:00;  < ici tu respécifie la fourchette horaire d'ouverture
> pour le jour en question entre 20h et 21h*
>
> *Donc c'est bien incohérent que tu veuilles le comprendre ou pas.*
> Tu et We ne sont pas en *off *et annule le comportement du jour en
> question sur le sélecteur précédent Mo-Fr en surchargeant le comportement
> vu que tu lui affecte une nouvelle plage horaire!
>
> le rôle additionnelle est le séparateur *, *pas *; les éléments séparé
> par des ; sont des *roles* qui écrase des valeurs précédemment défini de
> gauche à droite. Le mot clé off désactive des plages défini du comportement
> initial il sert à annuler des parties de critères mentionnés comme ouvert
> et là pas de problème tu as bon!*
>
> Rule separators
>  
> 
>  | 
> 
>  | 
> 
>  *;* 
> 
>  *,* 
> 
>  Limitations
> and Explanation
> 
> 
>
> 
> 
>  *||* 
> 
> Explanation
> 
>
> *A additional rule is treated exactly the same as a normal rule
>

Re: [OSM-talk-fr] absence de BAN dans BANO

2019-12-31 Par sujet marc marc 
Le 31.12.19 à 15:51, Christian Quest a écrit :
> la BAN sera dispo "avant la fin de l'année" sous Licence Ouverte, donc
> compatible avec l'ODbL d'OSM et de BANO.

je n'ai pourtant pas encore commencé le réveillon.
mais depuis quand l'obligation d'attribution de la LO est compatible
avec l'absence d'attribution des sources contribuant à osm ?
si j'affiche la carte d'un changeset provenant d'une source LO,
il y a pas d'attribution "donnée venant de cette source LO"
c'est pour cela qu'il me semblait qu'on devait se farcir
des demandes d'exeption pour que la source accepte de renoncer
à l'attribution et se contente d'être mentionné dans les sources
contribuant à osm

Je suis en tout cas ravi si la BANOv2 ou v3 (surtout ses outils
à la contribution osm) incluera la BAN en dernier resort.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] absence de BAN dans BANO

2019-12-31 Par sujet Vincent de Château-Thierry 

> De: "deuzeffe" 
> 
> Le 31/12/2019 à 15:51, Christian Quest a écrit :
> 
> > Cette convention est caduque, la BAN va enfin être totalement
> > ouverte...

Je réalise que la fin de la convention n'a pas eu de publicité ici ni sur la ML 
"Association", mais on en a parlé ici :
https://www.loomio.org/d/s3mrKhQT/ban-r-siliation-de-la-convention-de-2015-projet-d-accord-des-fondateurs

> > il n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2
> > :)
> 
> \o/

oui yapluka, un sujet pour le début de l'année :)

vincent

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

Re: [OSM-talk-fr] absence de BAN dans BANO

2019-12-31 Par sujet Philippe Verdy 
Le mar. 31 déc. 2019 à 15:52, Christian Quest  a
écrit :

> Comme l'a écrit vdct, la BAN sera dispo "avant la fin de l'année" sous
> Licence Ouverte, donc compatible avec l'ODbL d'OSM et de BANO.
>
> Donc on a laissé le champ libre pour que la BAN avance, et c'était aussi
> une façon de jouer le jeu vue la convention que nous avions signé.
>
> Cette convention est caduque, la BAN va enfin être totalement ouverte...
> il n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2 :)
>

En dehors des collectivités, l'arrivée de l'ARCEP pourrait inclure de
nouvelles données d'autres fournisseurs (pas que la Poste mais tous les
opérateurs de courrier et de télécommunications, et même des opérateurs de
réseaux, gaz/électricité, traitement des eaux, réseau ferré). Il serait
intéressant d'avoir les données de la Sécurité Civile (dont les pompiers)
et même pourquoi pas les armées (anciennes données de l'état-major), je ne
sais pas si c'est encore maintenu au delà des anciennes cartes, mais il
doit y avoir encore pas mal de terrains de l'armée accessibles au public),
les chambres d'agriculture, sociétés de chasse, agences de bassin, parcs
naturels, données forestières (pas encore incluse dans les données ONF),
Météo France, administration du littoral, etc... Pas toutes des adresses
mais des tas de lieux-dits et qui peuvent aussi aider les communes à nommer
leurs voies sur des bases bien fondées par un usage et la connaissance du
terrain et l'histoire.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] absence de BAN dans BANO

2019-12-31 Par sujet deuzeffe 

Le 31/12/2019 à 15:51, Christian Quest a écrit :

Cette convention est caduque, la BAN va enfin être totalement ouverte... 
il n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2 :)


\o/

(alors Marc-marc, heureux ? ^^)
--
deuzeffe - pas que lui, d'ailleurs...

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

Re: [OSM-talk-fr] absence de BAN dans BANO

2019-12-31 Par sujet Christian Quest 
Comme l'a écrit vdct, la BAN sera dispo "avant la fin de l'année" sous
Licence Ouverte, donc compatible avec l'ODbL d'OSM et de BANO.

Pourquoi n'avoir jamais intégré la BAN ODbL dans BANO ?

C'est un choix disons "politique"... la BAN a eu tellement de mal à naître
et à ne pas être enterrée dans la foulée, que côté BANO on s'est retenu de
faire la base la plus à jour et complète qui soit.

En effet, BANO a comme avantages:
- un cycle de mise à jour potentiellement plus court (une correction dans
OSM se retrouve le lendemain dans BANO)
- des sources plus diverses d'adresses (cadastre souvent mieux exploité
qu'il ne l'était dans la BAN "v0", des sources opendata venant des
collectivités)
- bien plus d'adresses sans numéro, typique pour les lieux-dits

Donc on a laissé le champ libre pour que la BAN avance, et c'était aussi
une façon de jouer le jeu vue la convention que nous avions signé.

Cette convention est caduque, la BAN va enfin être totalement ouverte... il
n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2 :)


Le mar. 31 déc. 2019 à 13:01, marc marc  a
écrit :

> Bonjour,
>
> Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
> Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
> Bano ne contient même pas l'adresse de la mairie
> et de nombreuses voies "sans adresse" dans BANO
> ont des adresses dans la BAN.
> ex Rue de Bourbouillon
>
> il parait qu'elle ne serra plus publiée à partir de demain :(
> p'tre que Christian en ferra un archivage :)
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] absence de BAN dans BANO

2019-12-31 Par sujet Philippe Verdy 
Ou alors "Guichet Ouvert" désigne aussi d'autres sources qui acceptent de
fournir leurs données, comme Waze, voire Google (données collectées par ses
streetcars ou les photos partagées par les utrilisateurs sur les sites
Google), ou encore Mapillary ?

Le mar. 31 déc. 2019 à 15:44, Philippe Verdy  a écrit :

> Intéressant, c'est surtout la base DGFip 2018 (BAN) qui est remplacé par
> la base DGFiP 2018 sous OdBl avec plus de sources (L'ARCEP en plus et
> bientôt sans doute à la place de La Poste.
> C'est le début de la fin de la BAN vers la base commune ODbL (totalement
> compatible BANO/OSM donc); je me demande pourtant l'intérêt du changement
> de l'ancvienne licence adhoc vers la LO/OL pour finalement n'y retrouver
> qu'une partie des données ODbL (le jeu qui devrait être le plus complet et
> le plus intéressant pour nous), puisque sous OL/LO on n'a pas la Poste (fin
> de vie de ce jeu de toute façon, remplacé par celui de l'ARCEP) ni les
> données IGN.
>
> Où est-on, nous OSM, dans le schéma
> https://adresse.data.gouv.fr/donnees-nationales: c'est nous le "Guichet
> Adresse" (inclus dans les trois jeux de données) ?
>
>
> Le mar. 31 déc. 2019 à 14:53, Vincent de Château-Thierry 
> a écrit :
>
>> Bonjour,
>>
>> > De: "marc marc" 
>> >
>> > Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
>> > Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
>> > Bano ne contient même pas l'adresse de la mairie
>> > et de nombreuses voies "sans adresse" dans BANO
>> > ont des adresses dans la BAN.
>> > ex Rue de Bourbouillon
>> >
>> > il parait qu'elle ne serra plus publiée à partir de demain :(
>> > p'tre que Christian en ferra un archivage :)
>>
>> Pas de panique, la BAN change de licence ce soir à minuit, sans pour
>> autant devenir incompatible avec OSM ni BANO :
>>
>> https://adresse.data.gouv.fr/donnees-nationales
>>
>> Et bon réveillon à tou.te.s
>>
>> 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] absence de BAN dans BANO

2019-12-31 Par sujet Philippe Verdy 
Intéressant, c'est surtout la base DGFip 2018 (BAN) qui est remplacé par la
base DGFiP 2018 sous OdBl avec plus de sources (L'ARCEP en plus et bientôt
sans doute à la place de La Poste.
C'est le début de la fin de la BAN vers la base commune ODbL (totalement
compatible BANO/OSM donc); je me demande pourtant l'intérêt du changement
de l'ancvienne licence adhoc vers la LO/OL pour finalement n'y retrouver
qu'une partie des données ODbL (le jeu qui devrait être le plus complet et
le plus intéressant pour nous), puisque sous OL/LO on n'a pas la Poste (fin
de vie de ce jeu de toute façon, remplacé par celui de l'ARCEP) ni les
données IGN.

Où est-on, nous OSM, dans le schéma
https://adresse.data.gouv.fr/donnees-nationales: c'est nous le "Guichet
Adresse" (inclus dans les trois jeux de données) ?


Le mar. 31 déc. 2019 à 14:53, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "marc marc" 
> >
> > Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
> > Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
> > Bano ne contient même pas l'adresse de la mairie
> > et de nombreuses voies "sans adresse" dans BANO
> > ont des adresses dans la BAN.
> > ex Rue de Bourbouillon
> >
> > il parait qu'elle ne serra plus publiée à partir de demain :(
> > p'tre que Christian en ferra un archivage :)
>
> Pas de panique, la BAN change de licence ce soir à minuit, sans pour
> autant devenir incompatible avec OSM ni BANO :
>
> https://adresse.data.gouv.fr/donnees-nationales
>
> Et bon réveillon à tou.te.s
>
> 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] absence de BAN dans BANO

2019-12-31 Par sujet Vincent de Château-Thierry 
Bonjour,

> De: "marc marc" 
> 
> Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
> Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
> Bano ne contient même pas l'adresse de la mairie
> et de nombreuses voies "sans adresse" dans BANO
> ont des adresses dans la BAN.
> ex Rue de Bourbouillon
> 
> il parait qu'elle ne serra plus publiée à partir de demain :(
> p'tre que Christian en ferra un archivage :)

Pas de panique, la BAN change de licence ce soir à minuit, sans pour autant 
devenir incompatible avec OSM ni BANO :

https://adresse.data.gouv.fr/donnees-nationales

Et bon réveillon à tou.te.s 

vincent

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

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

2019-12-31 Par sujet Jérôme Seigneuret 
C'est un truc de fou quand même d'être aussi têtu!
Tu me parles du comportement du mot clé *off. *Ca n'a rien à avoir avec ce
que je mentionne!

Pour rappel ta proposition c'est ça à la base
*Mo-Fr 11:45-14:00,17:00-20:00;*
*We 11:30-11:45; < ici tu n'ajoutes pas un horaire mais tu le respécifies
pour le jour en question*
*Mo 11:45-12:00 off; < là ok*
*We 13:00-14:00,18:00-20:00 off;< le off ne sert à rien mercredi a été
redéfini uniquement de 11h30 à 11h45*
*Tu 20:00-21:00;  < ici tu respécifie la fourchette horaire d'ouverture
pour le jour en question entre 20h et 21h*

*Donc c'est bien incohérent que tu veuilles le comprendre ou pas.*
Tu et We ne sont pas en *off *et annule le comportement du jour en question
sur le sélecteur précédent Mo-Fr en surchargeant le comportement vu que tu
lui affecte une nouvelle plage horaire!

le rôle additionnelle est le séparateur *, *pas *; les éléments séparé par
des ; sont des *roles* qui écrase des valeurs précédemment défini de gauche
à droite. Le mot clé off désactive des plages défini du comportement
initial il sert à annuler des parties de critères mentionnés comme ouvert
et là pas de problème tu as bon!*

Rule separators
 

 | 

 | 

 *;* 

 *,* 

Limitations
and Explanation





 *||* 

Explanation


*A additional rule is treated exactly the same as a normal rule
,
except that a additional rule does not overwrite the day for which it
applies (unlike the normal separator which starts always with a new, empty
day, deleting any pervious rules applying the given day). Note that a
additional rule does not use any data from previous or from following
rules. If time wraps over midnight are involved then you will probably also
need to use additional rules to not overwrite the part which wraps into the
next day. It can also be used to specify different comments

for
one day. Read more (including some examples) in this issue on github
.*

*Because of the peskiness that the 

is
the same token as the token to separate lists (e.g. 

{ , 

})
the , (comma) is only interpreted as 

if
it follows after one of those symbols:*

   - **
   

   - **
   



Il me semble que tu es meilleur en anglais que moi mais je n'ai pas inventé
ce que j'écris et || est bien dans la spécification en cours sinon c'est
que le wiki à besoin d'un petit rafraichissement comme le site
https://openingh.openstreetmap.de/evaluation_tool

La fallback empèche l'écrasement de valeur et est utilisé par défaut pour
présenter plusieurs situation avec c'est ça et ça avec des commentaires
pour préciser les deux situations. Informatique ça renvoi le bon résultat.

C'est loin d'être un critère de compatibilité vu que c'est dans les
spécifications officielle et que je comportement est opposé au mot clé
*off * c'est pas non plus remplacé vu que c'est encore dans le code source
avec des exemples ajouté en issues
https://openingh.ypid.de/netzwolf_mirror/time_domain/explanation.html
*Multiple rulesets can be concatenated using ||.   *

Maintenant on peut compléter avec l'auteur

et
le code source du projet les exemples pour voir la prise en compte ou non
de ce comportement.





Le mar. 31 déc. 2019 à 13:25, Philippe Verdy  a écrit :

> Bref:
> - "08:00-19:00;12:00-14:00 off" est équivalente à  "08:00- 12:00;14:00-
> 19:00"
> - "08:00-19:00;Sa-Su off" est équivalente à  "Mo-Th 08:00-19:

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

2019-12-31 Par sujet Jacques Lavignotte 



Le 31/12/2019 à 09:28, Jacques Lavignotte a écrit :

Je vais aller voir sur place.


Vu sur place :


Chemin : Rue des Libellules (72456629) est une allée privée qui dessert 
la maison en retrait de la rue des Libellules « Chemin : 84864716 »


Elle ne porte pas de plaque de rue.

La boîte à lettres et le numéro de rue (3) sont sur le muret en bord de 
rue « Chemin : Rue des Libellules (72456709) »



> C'est un chemin d'accès privé
> highway=service+service=driveway+
> access=private


Je l'ai fait, j'espère n'avoir rien cassé.


> sortir de la relation

J'ai tenté... que dira Osmose ?

A+

Jacques






!! Je reposte le dernier mail de Jérôme qui est probablement passé à la 
trappe pour quelques uns d'entre nous.




la supprimer non. la mettre en voie de service ça dépend. Pour une voie de
service privé j'ai tendance à faire du cas par cas.
Si les boites aux lettres sont au niveau du portail la voie est rarement
une voie nommé sauf cas de lotissement. Le point d'adresse est
souvent unique et dans ce cas je le met sur le portail et non à l'entrée
Une partie ou la totalité de la voie peut être privée. Les service postaux
on dans ce cas un badge d'accès. Les numéros sont bien matérialisé sur les
bâtiments.

Bref on a des lieu dit complet qui sont accessible qu'en voies privé avec
des postes barrières aux entrées. L'adressage n'est pas pour autant à
l'entrée du poste barrière... Les voies sont limités à 30km/h elle sont
nommé et servent au transit (sauf accès privé).

Par défaut une voie de service n'a pas de vitesse mais pour le routing
j'irai pas y mettre plus de 20km/h et en voie privé 10 km/h sauf indication
contraire. On peut considérer que la voie de service n'est pas utilisé pour
du transit. Elle ne sert qu'à une destination finale et/ou un service
particulier (c'est un principe de routing). On évite les voies de service
pour les itinéraires rapides et équilibré sauf si c'est le seul moyen
d'arriver au POI.

Chemin : Rue des Libellules (72456629)
C'est un chemin d'accès privé
highway=service+service=driveway+access=private  ainsi pas de suppression
de l'objet en tant que tel et il faut supprimer le nom de la voie et le
sortir de la relation

portail à ajouter:
barrier=gate+access=private

Pour les deux autres ways et les points d'adresses il faut tous mettre dans
une seule relation. C'est un extension de la voie existante
La partie présente au niveau du 22 et 24 et à découper est à mettre en
portion voie d'accès privé  highway=service+service=driveway+access=private
avec le portail qui va bien ;-)

Petite remarque sur la zone:
Les voies cyclables mentionnées autour n'en sont pas. Ceux sont des
trottoirs et il n'y a aucune signalisation à ma connaissance. Les trottoirs
abaissés c'est pour les poussettes et principalement pour les PMR. Donc il
faut tous remettre comme highway=footway et ajouter les mention d'accès
wheelchair=yes sauf si la signalisation aérienne ou au sol a évolué.
Peut-être voir avec Mickey86 
 à

la base de l'édition.

Bonne journée





Le 30/12/2019 à 23:41, marc marc a écrit :

Le 30.12.19 à 22:16, deuzeffe a écrit :

Chemin : Rue des Libellules (72456629)


Ce n'est pas une rue, mais une voie privée : elle fait partie intégrante
de la parcelle 450. Classique dans les lotissements arrangés façon
Tétris. À débaptiser et passer en highway=service ?


oui


Voire à supprimer ?


non car un jour un autre contributeur la recréera :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr





--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.


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

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

2019-12-31 Par sujet Philippe Verdy 
Il y a aussi un cas spécial pourtant assez courant:

Il arrive que le domaine public rue soit en totalité dans une seule commune
1 et pourtant il y a des adresses d'un côté de cette rue qui ne sont
accessibles que par elle mais en fait situées sur la commune 2 voisine.
Pour y accéder, uniquement une voie privée. L'adresse appartient bien à la
commune voisine 2. Dans certains cas, la commune voisine 2 ne référence pas
la rue dans le FANTOIR, et le point d'adresse a pourtant un numéro de la
commune 1 et utilise le nom de la commune 1.

Sur les adresses postales, l'adresse mentionne alors souvent les deux
communes dans l'usage courant, avec ce numéro, ce nom de rue, le code
postal de la commune 1, le nom de commune étant "commune 1/commune 2". Mais
la Poste accepte aussi juste "commune 2" sans mentionner "commune 1".

J'ai vu de telles rues apparaître et disparaître de façon instable dans le
FANTOIR selon les sources (la DGFIP, la Poste, la CCI, ou des versions
temporaires jamais finalisées, au gré visiblemetn de certains nettoyages
automatiques...). Normalement la commune 2 aurait du créer une entrée
FANTOIR pour cette rue même si elle n'est pas sur son territoire, afin d'y
mettre au moins les points d'adresse, même si la voie publique n'est pas
sur son territoire mais déborde sur la commune voisine. C'est fait
couramment dans plein de communes mais pas encore partout.

Dans OSM, le tracé filaire des rues peut ne pas suivre non plus exactement
la frontière administrative qui oscille autour du tracé actuel qui a été
régularisé (au gré des élargissements, modifications de carrefours,
giratoires, voies cyclables/bus, parfois aussi des zigzags imposés par des
stationnements alternant à droite et à gauche pour limiter la vitesse avec
une seule voie roulante et de cours segments pour se croiser et attendre.

L'inclusion géométrique stricte des rues n'a pas beaucoup de sens sur le
filaire d'OSM ou sur les points d'adresse qui ne représentent pas seul la
surface réellement désignée par une rue FANTOIR mais inclus aussi les
propriétés attenantes. La relation "associatedStreet" ou les points
d'adresse peuvent donc avoir dans certains cas des références FANTOIR d'une
autre commune que ce que désigne la surface de la relation administrative
communale. Si on avait une définition surfacique des rues, avec des
(multi)polygones englobants, on n'aurait pas ce "problème" lié à
l'insuffisance de la représentation filaire+noeuds d'adresses.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

2019-12-31 Par sujet Philippe Verdy 
Bref:
- "08:00-19:00;12:00-14:00 off" est équivalente à  "08:00- 12:00;14:00-
19:00"
- "08:00-19:00;Sa-Su off" est équivalente à  "Mo-Th 08:00-19:00"
- "Mo-Sa 08:00-19:00;Sa 18:00-19:00 off" est équivalente à  "Mo-Th
08:00-19:00;Sa 08:00-18:00"
Tu peux tester, c'est comme ça que ça marche.
Les règles séparées par ";" sont ordonnées de façon strictes, et elles sont
TOUTES évaluées cumulativement (on ne s'arrête pas au premier "match").
"||" ne sert strictement à rien (sauf à la compatibilité avec d'anciennes
spécifications qui ne marchaient pas dans plein de cas) et équivaut au ";".



Le mar. 31 déc. 2019 à 13:17, Philippe Verdy  a écrit :

>
>
> Le mar. 31 déc. 2019 à 09:18, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Le ; est une règle cumulative avec écrasement des valeurs passés.
>>
>> Si tu met Lundi au Vendredi de 10 à 20h et que tu ajoutes Mercredi de 20h
>> à 22h c'est pas cumulatif. Tu dis juste de remplacer les horaires de
>> Mercredi
>>
>
> C'est un non sens complet!
>
> L'indication: "08:00-19:00;Fr 18:00-19:00 off;Su off" indique clairement
> l'ouverture tous les jours de 8h à 19h, sauf le vendredi où ça ferme à 19h
> et le dimanche fermé.
>
>
> https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00&lat=48.84991979995&lon=2.6370411&mode=0&DATE=157773336&diff_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00
>
>
> L'interprétation est bien cumulative et se fait dans l'ordre, chaque règle
> séparée par ";" modifiant les précédentes.
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

2019-12-31 Par sujet Philippe Verdy 
Le mar. 31 déc. 2019 à 09:18, Jérôme Seigneuret 
a écrit :

> Le ; est une règle cumulative avec écrasement des valeurs passés.
>
> Si tu met Lundi au Vendredi de 10 à 20h et que tu ajoutes Mercredi de 20h
> à 22h c'est pas cumulatif. Tu dis juste de remplacer les horaires de
> Mercredi
>

C'est un non sens complet!

L'indication: "08:00-19:00;Fr 18:00-19:00 off;Su off" indique clairement
l'ouverture tous les jours de 8h à 19h, sauf le vendredi où ça ferme à 19h
et le dimanche fermé.

https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00&lat=48.84991979995&lon=2.6370411&mode=0&DATE=157773336&diff_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00


L'interprétation est bien cumulative et se fait dans l'ordre, chaque règle
séparée par ";" modifiant les précédentes.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] absence de BAN dans BANO

2019-12-31 Par sujet marc marc 
Bonjour,

Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
Bano ne contient même pas l'adresse de la mairie
et de nombreuses voies "sans adresse" dans BANO
ont des adresses dans la BAN.
ex Rue de Bourbouillon

il parait qu'elle ne serra plus publiée à partir de demain :(
p'tre que Christian en ferra un archivage :)

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

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

2019-12-31 Par sujet Jacques Lavignotte 

Je vais aller voir sur place.



!! Je reposte le dernier mail de Jérôme qui est probablement passé à la 
trappe pour quelques uns d'entre nous.




la supprimer non. la mettre en voie de service ça dépend. Pour une voie de
service privé j'ai tendance à faire du cas par cas.
Si les boites aux lettres sont au niveau du portail la voie est rarement
une voie nommé sauf cas de lotissement. Le point d'adresse est
souvent unique et dans ce cas je le met sur le portail et non à l'entrée
Une partie ou la totalité de la voie peut être privée. Les service postaux
on dans ce cas un badge d'accès. Les numéros sont bien matérialisé sur les
bâtiments.

Bref on a des lieu dit complet qui sont accessible qu'en voies privé avec
des postes barrières aux entrées. L'adressage n'est pas pour autant à
l'entrée du poste barrière... Les voies sont limités à 30km/h elle sont
nommé et servent au transit (sauf accès privé).

Par défaut une voie de service n'a pas de vitesse mais pour le routing
j'irai pas y mettre plus de 20km/h et en voie privé 10 km/h sauf indication
contraire. On peut considérer que la voie de service n'est pas utilisé pour
du transit. Elle ne sert qu'à une destination finale et/ou un service
particulier (c'est un principe de routing). On évite les voies de service
pour les itinéraires rapides et équilibré sauf si c'est le seul moyen
d'arriver au POI.

Chemin : Rue des Libellules (72456629)
C'est un chemin d'accès privé
highway=service+service=driveway+access=private  ainsi pas de suppression
de l'objet en tant que tel et il faut supprimer le nom de la voie et le
sortir de la relation

portail à ajouter:
barrier=gate+access=private

Pour les deux autres ways et les points d'adresses il faut tous mettre dans
une seule relation. C'est un extension de la voie existante
La partie présente au niveau du 22 et 24 et à découper est à mettre en
portion voie d'accès privé  highway=service+service=driveway+access=private
avec le portail qui va bien ;-)

Petite remarque sur la zone:
Les voies cyclables mentionnées autour n'en sont pas. Ceux sont des
trottoirs et il n'y a aucune signalisation à ma connaissance. Les trottoirs
abaissés c'est pour les poussettes et principalement pour les PMR. Donc il
faut tous remettre comme highway=footway et ajouter les mention d'accès
wheelchair=yes sauf si la signalisation aérienne ou au sol a évolué.
Peut-être voir avec Mickey86 
 à

la base de l'édition.

Bonne journée





Le 30/12/2019 à 23:41, marc marc a écrit :

Le 30.12.19 à 22:16, deuzeffe a écrit :

Chemin : Rue des Libellules (72456629)


Ce n'est pas une rue, mais une voie privée : elle fait partie intégrante
de la parcelle 450. Classique dans les lotissements arrangés façon
Tétris. À débaptiser et passer en highway=service ?


oui


Voire à supprimer ?


non car un jour un autre contributeur la recréera :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.


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

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

2019-12-31 Par sujet Jérôme Seigneuret 
Le ; est une règle cumulative avec écrasement des valeurs passés.

Si tu met Lundi au Vendredi de 10 à 20h et que tu ajoutes Mercredi de 20h à
22h c'est pas cumulatif. Tu dis juste de remplacer les horaires de Mercredi
Dans ce cas il faut utiliser le *|| *et non* ; *

L'évaluation se fait de gauche à droite Si on ajoute un nouveau sélecteur
celui-ci surchage les valeur précédente ou ajoute des horaires non
précédemment défini pour le jour en question.
Même si tu spécifie des plages horaire le selecteur c'est le jour complet
donc si tu ajoutes des nouveaux horaires c'est l'horaire de la journée
complète qui est réévalué.
Le double pipe à un comportement cumulatif des plages non couvertes

*voici les exemples*
Mo-Fr 10:00-20:00; We 20:00-22:00
https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00&lat=48.84991979995&lon=2.6370411&mode=0&DATE=157773336&diff_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00


Mo-Fr 10:00-20:00|| We 20:00-22:00
https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%7C%7C%20We%2020%3A00-22%3A00&lat=48.84991979995&lon=2.6370411&mode=0&DATE=157773336&diff_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00


Maintenant comme je l'ai présenté précédemment il est possible de coupler
les séparateurs ; et tu peux surement améliorer ma proposition ou corriger
la tienne en exploitant || et en testant ;-)
Bonne journée

Le mar. 31 déc. 2019 à 00:37, Philippe Verdy  a écrit :

>
>
> Le lun. 30 déc. 2019 à 21:02, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Salut,
>> "Journée continue"  n'est pas nécessaire si l'on utilise le mot clé
>> "off". Attention YoHours ne prend pas en compte toute la syntaxe de
>> opening_hours
>> exemple complet pour les vacances
>>
>> https://openingh.openstreetmap.de/evaluation_tool/?EXP=SH%2010%3A00-18%3A00%3B%20SH%20Sa%2CSu%2013%3A00-15%3A00%20off&lat=48.84991979995&lon=2.6370411&mode=0&DATE=1577733402192
>>
>>
>> @Philippe l'ajout d'un sélecteur écrase la valeur précédente donc tu va
>> avoir un problème sur le mercredi et sur le jeudi. Dans ton cas, jeudi ne
>> sera ouvert que de 20h à 21h et Mercredi de 11h30 à 11h45
>> Il faut aussi ajouter PH off pour une fermeture les jours fériés si c'est
>> le cas.
>>
>
> Non, chaque valeur listée vient modifier les valeurs précédentes dans les
> plages horaires indiquées; les règles sont cumulatives, et ordonnées, mais
> dans ce cas il n'y a même pas d'écrasement, une première règle indique la
> plage "standard" du lundi au vendredi, les autres pour les jours
> particuliers viennent modifier encore ce qui est défini. Quand on "parse"'
> les règles au début la règle par défaut est "off" partout, chaque règle ne
> modifie que les plages indiquées.
>
> Mais que penser de ma proposition de rendre tous les espaces facultatifs
> sauf entre 2 lettres ou entre deux chiffres dans la syntaxe existante; ce
> qui permettrait de les supprimer pour compacter encore plus (et c'est
> facile de restaurer ces espaces "implicites" entre une lettre et un
> chiffre. Je ne vois aucune règle existante où cela conduit à une ambiguïté
> quelconque.
>
> Ca peut éventuellement casser certaines analyses lexicales mais le patch
> lexical est simple à faire, on a pratiquement besoin d'aucune espace dans
> la plupart des cas (sauf par exemple "Jul-Aug off" pour indiqué "fermé en
> juillet et août" et qu'on ne peut pas compacter en "Jul-Augoff" car cette
> espace est entre deux lettres). C'est pas une révolution, mais au moins si
> ça peut aider à passer la limite des 255 caractères par valeur de tag...
>
>

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

2019-12-31 Par sujet Jérôme Seigneuret 
la supprimer non. la mettre en voie de service ça dépend. Pour une voie de
service privé j'ai tendance à faire du cas par cas.
Si les boites aux lettres sont au niveau du portail la voie est rarement
une voie nommé sauf cas de lotissement. Le point d'adresse est
souvent unique et dans ce cas je le met sur le portail et non à l'entrée
Une partie ou la totalité de la voie peut être privée. Les service postaux
on dans ce cas un badge d'accès. Les numéros sont bien matérialisé sur les
bâtiments.

Bref on a des lieu dit complet qui sont accessible qu'en voies privé avec
des postes barrières aux entrées. L'adressage n'est pas pour autant à
l'entrée du poste barrière... Les voies sont limités à 30km/h elle sont
nommé et servent au transit (sauf accès privé).

Par défaut une voie de service n'a pas de vitesse mais pour le routing
j'irai pas y mettre plus de 20km/h et en voie privé 10 km/h sauf indication
contraire. On peut considérer que la voie de service n'est pas utilisé pour
du transit. Elle ne sert qu'à une destination finale et/ou un service
particulier (c'est un principe de routing). On évite les voies de service
pour les itinéraires rapides et équilibré sauf si c'est le seul moyen
d'arriver au POI.

Chemin : Rue des Libellules (72456629)
C'est un chemin d'accès privé
highway=service+service=driveway+access=private  ainsi pas de suppression
de l'objet en tant que tel et il faut supprimer le nom de la voie et le
sortir de la relation

portail à ajouter:
barrier=gate+access=private

Pour les deux autres ways et les points d'adresses il faut tous mettre dans
une seule relation. C'est un extension de la voie existante
La partie présente au niveau du 22 et 24 et à découper est à mettre en
portion voie d'accès privé  highway=service+service=driveway+access=private
avec le portail qui va bien ;-)

Petite remarque sur la zone:
Les voies cyclables mentionnées autour n'en sont pas. Ceux sont des
trottoirs et il n'y a aucune signalisation à ma connaissance. Les trottoirs
abaissés c'est pour les poussettes et principalement pour les PMR. Donc il
faut tous remettre comme highway=footway et ajouter les mention d'accès
wheelchair=yes sauf si la signalisation aérienne ou au sol a évolué.
Peut-être voir avec Mickey86   à
la base de l'édition.

Bonne journée


Le lun. 30 déc. 2019 à 23:41, marc marc  a
écrit :

> Le 30.12.19 à 22:16, deuzeffe a écrit :
> >> Chemin : Rue des Libellules (72456629)
> >
> > Ce n'est pas une rue, mais une voie privée : elle fait partie intégrante
> > de la parcelle 450. Classique dans les lotissements arrangés façon
> > Tétris. À débaptiser et passer en highway=service ?
>
> oui
>
> > Voire à supprimer ?
>
> non car un jour un autre contributeur la recréera :)
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr