Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[david . crochet]

Bonjour

- Mail original -
De: "Arnaud Champollion" 
À: talk-fr@openstreetmap.org


On a des écoles élémentaire, des écoles maternelles, et des écoles primaires 
(mater+elem). Chacun de ces cas demande un seul amenity=school, sinon ça fait 
des doublons sur les rendus et sur les recherches de données. 

- Mail original -

1 établissement scolaire, ou plutôt une entité administrative, c'est 1 n° 
d'identification que l'on appelle UAI pour unité administrative immatriculée  :

3 premiers chiffres (095) qui correspondent au département (par exemple 012 
pour l’Aveyron, 095 pour le Val-d’Oise, 974 pour la Réunion...) ;
4 chiffres (1099) qui permettent d’identifier un établissement de façon unique 
dans le département ;
1 lettre (D) qui sert de checksum (ou somme de contrôle) pour vérifier la bonne 
saisie du code.

Cette dernière lettre est calculée ainsi :

on prend le nombre composé par les 7 premiers chiffres (exemple : 0951099) ;
on divise ce nombre par 23 et on garde le reste (exemple : reste de 
(0951099/23) = 3) ;
on prend ensuite les lettres de l’alphabet auxquelles on a enlevé les I, O et Q 
soient 23 lettres (a,b,c,d,e,f,g,h,j,k,l,m,n,p,r,s,t,u,v,w,x,y,z) ;
la lettre choisie est celle de la position reste + 1 (exemple : position 3+1=4, 
soit la lettre D).


Dans l'histoire, un emprise géographie, ou plutot parcellaire, peut contenir 
plusieurs établissement scolaire :
Un collège peut contenir une SGPA, donc 2 UAI pour 1 emprise géographique
Un LP et un LEGT, un LEGT et une SEP, etc. 

parfois, c'est un bâtiment, parfois, ce ne sont que des salles, parfois c'est 
juste une bureau.

Cordialement

-- 
David Crochet

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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[Vincent Bergeot]

Le 18/12/2019 à 08:14, Arnaud Champollion a écrit :

Le 17/12/2019 à 10:35, Vincent Bergeot a écrit :

Mais du coup ça crée plusieurs amenity=school pour une seule entité.

Si par exemple on fait une requête overpass (par exemple pour 
obtenir les écoles du département et les afficher sur Umap) on ne 
risque pas de se retrouver avec des doublons ?


oui et cela dépendra de la requête, du type d'écoles attendues. 
school, school:FR, ...


[amenity=school][school:FR=élémentaire] ne renvoie normalement pas de 
doublons dans le cas évoqué 


Après avoir manipulé, lu toutes les interventions et autres docs, je 
pense qu'il faut qu'il y ait qu'un seul amenity=school par école.


Une école = une direction d'école = une entité = un amenity=school

c'est la définition administrative, pas forcément celle que l'on peut 
voir sur le terrain. Que cela soit l'intention administrative, ok mais 
pour beaucoup de cas je pense qu'il y a encore écrit école maternelle 
(même si c'est une école primaire :) )


On a des écoles élémentaire, des écoles maternelles, et des écoles 
primaires (mater+elem). Chacun de ces cas demande un seul 
amenity=school, sinon ça fait des doublons sur les rendus et sur les 
recherches de données.


j'entends très bien ce que tu écris (vraiment car je l'ai croisé un 
paquet de fois), cependant une école primaire avec une entrée pour la 
maternelle et un entrée pour l'élémentaire est aussi une réalité, la 
séparation des cours et des bâtiments sont souvent aussi des réalités du 
terrain.


Exemple avec Geodatamine : 
https://geodatamine.fr/data/education/-85909?format=csv&aspoint=true


Dans l'état actuel des données OSM, le CSV généré renvoie davantage 
d'école qu'il n'y en a en réalité (L'école Paul Martin apparaît 
plusieurs fois, alors qu'il s'agit bien de la même école).


et peut-être que le problème est ailleurs alors car la requête sur 
amenity=school renvoie aussi les crêches, le conservatoire de musique, 
l'appase, l'école d'infirmiers, l'iut


peut-être faut-il des requêtes qui demande "seulement" 
[school:FR=primaire AND school:FR=élémentaire AND school:FR=maternelle 
si on parle du premier degré]


exemple ici : http://overpass-turbo.eu/s/P41


Je suppose que ce problème des doublons est identique pour tous les 
jeux de données.


oui l'extraction des données est souvent complexe :) mais pas toujours 
un problème au niveau des données (attention je ne cherche pas à dire 
qu'il n'y aurait pas des améliorations possible des modèles de données, 
y compris sur school !)


à plus






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



--
Vincent Bergeot

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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[Arnaud Champollion]

Le 17/12/2019 à 10:35, Vincent Bergeot a écrit :

Mais du coup ça crée plusieurs amenity=school pour une seule entité.

Si par exemple on fait une requête overpass (par exemple pour obtenir 
les écoles du département et les afficher sur Umap) on ne risque pas 
de se retrouver avec des doublons ?


oui et cela dépendra de la requête, du type d'écoles attendues. 
school, school:FR, ...


[amenity=school][school:FR=élémentaire] ne renvoie normalement pas de 
doublons dans le cas évoqué 


Après avoir manipulé, lu toutes les interventions et autres docs, je 
pense qu'il faut qu'il y ait qu'un seul amenity=school par école.


Une école = une direction d'école = une entité = un amenity=school

On a des écoles élémentaire, des écoles maternelles, et des écoles 
primaires (mater+elem). Chacun de ces cas demande un seul 
amenity=school, sinon ça fait des doublons sur les rendus et sur les 
recherches de données.


Exemple avec Geodatamine : 
https://geodatamine.fr/data/education/-85909?format=csv&aspoint=true


Dans l'état actuel des données OSM, le CSV généré renvoie davantage 
d'école qu'il n'y en a en réalité (L'école Paul Martin apparaît 
plusieurs fois, alors qu'il s'agit bien de la même école).


Je suppose que ce problème des doublons est identique pour tous les jeux 
de données.



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

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[François Lacombe]

Le mer. 18 déc. 2019 à 02:06, Jérôme Amagat  a
écrit :

>
> Donc si on suis cette logique, il faut changer en building=tourism tous
> les hôtels, en building=amenity tous les restaurants, lieu de culte, bar,
> école... pour avoir une belle chaîne de tag.
>

Uniquement si le bâtiment est complètement dédié à ces destinations, en
tout cas pour ce qui nous intéresse ici.
Que ce principe ne soit pas en vigueur partout, c'est en partie à cause de
l'historique (particulièrement marqué sur building) et aussi parce que
certains concepts ne sont pas aussi liés que la destination d'un bâtiment
aux équipements qu'il héberge.

OSM est une base sémantique, chaîner les concepts me semble être une
pratique vertueuse.
Utiliser deux termes, service sur building et utility ensuite, pour la même
chose n'est pas bon non plus (et on ne redéfinira pas service=* pour ça)


> On le laisse comme on laisse building=church sur une église reconverti en
> musée, habitation...
> C'est la plupart du temps la destination première du bâtiment que l'on met
> dans building=* mais si l'utilisation change le tag building=* ne doit pas
> changer.
>

Ce qui rend la signification de building=* moins claire que ce je
pensais... c'est la destination, puis la forme, on ne sais pas bien.
La première destination d'un bâtiment remonte à autant qu'on puisse se
souvenir... c'est plutôt pas clair.


> Il est beaucoup utilisé, ce qui posera sûrement problème, mais facile à
>> comprendre, non
>> Service ça veut tout et rien dire, vraiment.
>>
>
> C'st plus facile à comprendre que "utility" !
>

Question d'appréciation, je ne sais toujours pas ce que veux dire service
(intrinsèquement, sinon j'ai bien lu le wiki). Qu'est-ce que tu comprends ?
Par contre utility, on a une définition et un périmètre clairs, au moins
pour les pays développés : https://en.wikipedia.org/wiki/Public_utility


> D'ailleurs le bâtiment qui stocke le sel pour le déneigement des routes à
>> côté de chez moi, c'est building=service ou pas ? (parce que c'est pas une
>> "utility" mais les véhicules garés devant sont tous stickés "SERVICE").
>>
>
> Je dirais que si le bâtiment a été construit pour le stockage c'est plutôt
> building=warehouse.
>

D'accord avec ça

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

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[osm . sanspourriel]

Le 18/12/2019 à 00:28, François Lacombe - fl.infosrese...@gmail.com a
écrit :


Si on documente la destination d'un bâtiment, pourquoi devrait-on
laisser building=garage si celui-ci deviens une habitation?
Il y a bien des silos de lancement de missiles balistiques qui
deviennent des appartements, on voit de tout.


Tant qu'ils ont l'aspect typique de l'objet précédent ça a un sens. Ce
n'est pas la destination mais l'aspect qui compte.

Après si tu mets par exemple un toit pentu sur le garage,
building=garage sera remplacé par building=house.

Le 18/12/2019 à 02:05, Jérôme Amagat - jerome.ama...@gmail.com a écrit :

Donc si on suis cette logique, il faut changer en building=tourism
tous les hôtels, en building=amenity tous les restaurants, lieu de
culte, bar, école... pour avoir une belle chaîne de tag.


Pourquoi pas mais seulement si c'est une architecture typique.

Le 18/12/2019 à 02:05, Jérôme Amagat - jerome.ama...@gmail.com a écrit :


Service ça veut tout et rien dire, vraiment.


C'st plus facile à comprendre que "utility" !


Il faut effectivement penser aux locuteurs étrangers (non britanniques).
Je pense que l'avis de Jérôme reflète le cas de la majorité des Français.

Et pour services style garagiste, il y a aussi la station-service... où
maintenant c'est toi qui fait le service !

Et c'est vrai que si je vois ce que sont les "utilities", j'aurais
tendance à focaliser sur les entreprises du secteur énergétique (et non
à l'ensemble des services de réseau).

Jean-Yvon

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

Re: [OSM-talk-fr] Joli noms de rues

[osm . sanspourriel]

Le 16/12/2019 à 19:54, Jérôme Amagat - jerome.ama...@gmail.com a écrit :

le "rue du Repos pour ne pas dire "cimetière" est un peu mieux...


Voir la rue de l'avenir mais il faut un conseil municipal pourvu
d'humour. Et les administrés aussi !

Le 16/12/2019 à 21:58, Christian Rogel -
christian.ro...@club-internet.fr a écrit :

Ce qui est demandé, c’est que l’on exploite le nom lieu incrit dans le cadastre 
pour nommer les voies.

+1, ça s'appelle le bon sens

Par ailleurs, sachant que c’est la commune qui a tous les pouvoirs sur la forme 
des noms de voie, rien ne l’oblige à choisir « générique »  en français (rue, 
allée…), si elle préfère qe ce générique soit dans une autre langue (hent, 
carrer, strasse, etc.) ou, pourquoi pas, l’absence de générique.
C’est donc à la Poste d’enregistrer tous les génériques possibles et de 
s’adapter au terrain et no l’inverse.
D’autant qu’il s’agit, aujourd’hui, d’un organise privé.


Les génériques dans le cas de strasse sont à la fin.

Et Gerberstrasse, c'est le rue des tanneurs, ce n'est pas à côté de la
rue de la soif^^ (qui n'ont pas toutes été renommées Rue Saint-Michel
 - alors que là l'usage
persiste)


L’espoir pourrait venir de… l’IGN qui pourrait faire ce travail si évident. Et 
comme l’IGN alimente la BAN qui pourrait parvenir aux oreilles des maires…un


Ou les cartographes d'OSM, je ne sais si tu en as entendu parler.

Ce sont des gens bizarres avec notamment un type encore plus bizarre
qu'ils appellent vdct. Non seulement ils créent une carte alors que
Google fait le boulot gratuitement heu met à disposition gratuitement
heu met à disposition contre argent une carte.

Avec des quartiers nommé par Google. Et au final tu donnes ton adresse
Google.

Ce vdct il fait des trucs de dingue. Il a été "recruté" pas un autre
fana, Christian du même genre. Je mets des guillemets car ils
travaillent bénévolement. Et puis pour faire ce qu'ils font tous les
deux, il faudrait plusieurs service de l'IGN.

Et bien imagine toi ces gens-là mettent à disposition les lieux-dits du
cadastre.
Et d'autres bénévoles les intègrent dans la carte, un truc de ouf.

Et un promoteur en mal d'inspiration ou au contraire inspiré va utiliser
ces toponymes pour nommer ses prestations.

Le 16/12/2019 à 22:27, Philippe Verdy - verd...@wanadoo.fr a écrit :

Certains noms sont historiques: un service peut disparaître aussi,
comme "Rue de la Gare" (alors qu'il n'y a plus de gare ni même de voie
ferrée) et ne rend plus service à personne.


Par contre le bâtiment gare peut être resté. C'est alors comme l'église
qui a changé de destination : ce n'est plus une gare ou une église, et
ça ne rend plus ce service. Une gare qui sert d'office de tourisme
 ça a une utilité mais plus
la même et sert toujours de repère dans le paysage.

Tiens il faudra changer ce building=yes.


De même "Rue de la Mare" quand il n'y a plus de mare non plus. Ou
Place de grève à Paris quand il n'y a plus de grève (en tant cas pas
avec le même sens qu'on comprend aujourd'hui). Le service est utile
mais limité dans le temps quand le service est déplacé ailleurs (une
marie, un cimetière).


La place de grève

s'appelle /Place de l'Hôtel-de-Ville - Esplanade de la Libération/ et
était une grève (au sens du lieu formé de gravier sur une rive) et a
donné le nom de grève pour l'embauche et in fine pour faire grève dans
le sens de refuser l'embauche et rester sur la place de grève.

Vu que ça a créé l'acceptation du sens faire grève c'est un peu bête de
ne pas avoir gardé le nom. D'ailleurs je crois que les endroits ou les
dockers embauchaient (quand ils étaient journaliers - et pas des images
oui j'ai osé^^) s'appelaient place de grève par imitation de la place de
Paris.


Tant qu'à faire autant utiliser "Rue/route du ", au
moins les hameaux et lieux-dits persistent longtemps à moins que tout
soit démoli et plus habité. Quant à "Rue de 
c'est souvent assez ambigu quadn ce n'est même plus le chemin préféré
pour y aller suite à un changement de plan de circulation.

Et ça devient "ancienne route de Trucmuch", bof effectivement. Ou trop
peu descriptif, comme cette Rue de la Rade
 à Roskañvel (toutes les
routes est-ouest côté Est peuvent porter ce nom).


Maintenant j'aime bien les noms insolites, comme "Rue de la Pie qui
boit" (je vous laisse chercher où) qui évoque toute une histoire à
raconter, un folklore, une ancienne tradition, ou une invention d'un
auteur pour une scène de oman, de théatre ou de cinéma se passant dans
la commune.


Effectivement je me rappelai l'avoir remarquée en passant mais je ne me
souvenais plus de la ville. Merci Nominatim.


Mais d'une façon générale, si une rue héberge un monument ou
quelquechose de remarquable comme un bâtiment classé, c'est une
mauvaise id

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[Jérôme Amagat]

Le mer. 18 déc. 2019 à 00:29, François Lacombe 
a écrit :

> Bonsoir Jérôme,
>
> Le lun. 16 déc. 2019 à 01:34, Jérôme Amagat  a
> écrit :
>
>>
>> C'est joli mais qu'est ce que ça apporte de plus comme info que
>> building=service + power=substation + substation=minor_distribution ?
>>
>
> Avec building=service, on se sais pas de quel service il peut s'agir.
> Un garagiste c'est aussi un service finalement (on me l'a déjà sorti plein
> de fois).
>
> Il est réellement intéressant de pouvoir construire des chaînes comme ce
> que je montrais dans le mail du dessus.
> Si le consommateur est intéressé pour trouver tout le bâti impliqué dans
> les utilités, il ne connaît peut-etre pas les valeurs plus spécifiques
> comme power=substation et il peut en oublier.
>

Donc si on suis cette logique, il faut changer en building=tourism tous les
hôtels, en building=amenity tous les restaurants, lieu de culte, bar,
école... pour avoir une belle chaîne de tag.

>
>
>>  L'architecture d'un garage est le plus souvent très éloigné de celle
>> d'une maison, ou d'une église. Ce qui ressemble le plus à un garage c'est
>> un autre garage, une grande porte, pas ou seulement des petites ouverture,
>> bâtiment pas très haut, ils sont pas tous comme ça mais beaucoup. Pour
>> building=service on peut faire la même chose, il y a sûrement plus de cas
>> différents que pour le garage.
>> Malgré ça je suis d'accord que ce que l'on met dans building=* donne plus
>> d'info sur à quoi il sert que sur le bâtiment en lui même mais on demande
>> par exemple de laissé building=church même si ça ne sert plus de lieu de
>> culte et il faudrait laissé building=garage même si le bâtiment est devenu
>> (sans trop de modif) une habitation...
>>
>
> Si on documente la destination d'un bâtiment, pourquoi devrait-on laisser
> building=garage si celui-ci deviens une habitation?
>

On le laisse comme on laisse building=church sur une église reconverti en
musée, habitation...
C'est la plupart du temps la destination première du bâtiment que l'on met
dans building=* mais si l'utilisation change le tag building=* ne doit pas
changer.
la page du wiki donne le tag building:use=* pour l'usage (
https://wiki.openstreetmap.org/wiki/Key:building) mais je ne n'ai jamais
utilisé ce tag.
La plupart du temps l'usage on l'ajoute avec d'autre tag, un bâtiment qui
sert de restaurant c'est amenity=restaurant quelque soit le tag building=*


> Il y a bien des silos de lancement de missiles balistiques qui deviennent
> des appartements, on voit de tout.
>

le bâtiment doit être tagué avec building=missile silo ou quelque chose
comme ça.

>
>
>> Si j'en reviens au problème de départ :) , rien n’empêche d'indiquer avec
>> un autre tag à quoi sert ce bâtiment et pourquoi pas avec utility=*, on
>> peut déjà le faire avec d'autres tags, par exemple, une église convertie en
>> musée c'est building=church + tourism=museum il n'y a pas besoin de
>> building=tourism ou autre chose.
>> On peut privilégié une valeur comme building=utility lorsque le bâtiment
>> a été construit à cet effet mais je pense que building=service a l'avantage
>> d'être plus simple à comprendre et est déjà beaucoup utilisé.
>>
>
> Il est beaucoup utilisé, ce qui posera sûrement problème, mais facile à
> comprendre, non
> Service ça veut tout et rien dire, vraiment.
>

C'st plus facile à comprendre que "utility" !


> D'ailleurs le bâtiment qui stocke le sel pour le déneigement des routes à
> côté de chez moi, c'est building=service ou pas ? (parce que c'est pas une
> "utility" mais les véhicules garés devant sont tous stickés "SERVICE").
>

Je dirais que si le bâtiment a été construit pour le stockage c'est plutôt
building=warehouse.


> Même si le wiki semble utiliser building=service pour building=utility, je
> ne suis pas sûr en plus que toutes les occurrences soient concernées par le
> changement proposé. Certains bâtiments ne doivent pas être des sites
> techniques d'utilités à proprement parler.
>
> Bref, il y a besoin d'en discuter encore un peu
>
> Bonne soirée
>
> François
>
>
>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[François Lacombe]

Bonsoir Jérôme,

Le lun. 16 déc. 2019 à 01:34, Jérôme Amagat  a
écrit :

>
> C'est joli mais qu'est ce que ça apporte de plus comme info que
> building=service + power=substation + substation=minor_distribution ?
>

Avec building=service, on se sais pas de quel service il peut s'agir.
Un garagiste c'est aussi un service finalement (on me l'a déjà sorti plein
de fois).

Il est réellement intéressant de pouvoir construire des chaînes comme ce
que je montrais dans le mail du dessus.
Si le consommateur est intéressé pour trouver tout le bâti impliqué dans
les utilités, il ne connaît peut-etre pas les valeurs plus spécifiques
comme power=substation et il peut en oublier.


>  L'architecture d'un garage est le plus souvent très éloigné de celle
> d'une maison, ou d'une église. Ce qui ressemble le plus à un garage c'est
> un autre garage, une grande porte, pas ou seulement des petites ouverture,
> bâtiment pas très haut, ils sont pas tous comme ça mais beaucoup. Pour
> building=service on peut faire la même chose, il y a sûrement plus de cas
> différents que pour le garage.
> Malgré ça je suis d'accord que ce que l'on met dans building=* donne plus
> d'info sur à quoi il sert que sur le bâtiment en lui même mais on demande
> par exemple de laissé building=church même si ça ne sert plus de lieu de
> culte et il faudrait laissé building=garage même si le bâtiment est devenu
> (sans trop de modif) une habitation...
>

Si on documente la destination d'un bâtiment, pourquoi devrait-on laisser
building=garage si celui-ci deviens une habitation?
Il y a bien des silos de lancement de missiles balistiques qui deviennent
des appartements, on voit de tout.


> Si j'en reviens au problème de départ :) , rien n’empêche d'indiquer avec
> un autre tag à quoi sert ce bâtiment et pourquoi pas avec utility=*, on
> peut déjà le faire avec d'autres tags, par exemple, une église convertie en
> musée c'est building=church + tourism=museum il n'y a pas besoin de
> building=tourism ou autre chose.
> On peut privilégié une valeur comme building=utility lorsque le bâtiment a
> été construit à cet effet mais je pense que building=service a l'avantage
> d'être plus simple à comprendre et est déjà beaucoup utilisé.
>

Il est beaucoup utilisé, ce qui posera sûrement problème, mais facile à
comprendre, non
Service ça veut tout et rien dire, vraiment.
D'ailleurs le bâtiment qui stocke le sel pour le déneigement des routes à
côté de chez moi, c'est building=service ou pas ? (parce que c'est pas une
"utility" mais les véhicules garés devant sont tous stickés "SERVICE").
Même si le wiki semble utiliser building=service pour building=utility, je
ne suis pas sûr en plus que toutes les occurrences soient concernées par le
changement proposé. Certains bâtiments ne doivent pas être des sites
techniques d'utilités à proprement parler.

Bref, il y a besoin d'en discuter encore un peu

Bonne soirée

François



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

Re: [OSM-talk-fr] Rendu transport routier...

[Christian Quest]

Aucune idée, pour cet itinéraire à 120t, l'info provient du département.
Chaque département produit une carte avec les itinéraires pour les convois
exceptionnels.

Pour les hauteurs maxi, le panneau est obligatoire en dessous de 4,30m. Il
me semble que sur les autoroutes, l'indication commence au delà.

Rien trouvé lors d'une rapide et délicieuse* lecture des instructions
interministérielles sur la signalisation routières (IISR) qu'on peut
consulter ici:
http://www.equipementsdelaroute.equipement.gouv.fr/les-versions-actualisees-des-9-parties-de-l-a528.html

* déliceuse quand je suis passé voir ce qui se racontait sur les panneaux
biche ;)


Le mar. 17 déc. 2019 à 21:31, pepilepi...@ovh.fr  a
écrit :

> Le 17/12/2019 à 17:00, Christian Quest a écrit :
>
> Bug corrigé, halo passé en gris (rouge ça faisait "bouchons")
>
> *72 t*... *petit joueur*:
> http://osm.cquest.org/fortissimo/#14/48.1961/3.3036
>
> C'est un concours à qui qu'a la plus grosse ?
>
> Juste pour ma culture, quel est le poids maxi par défaut, c'est à dire en
> l'absence de toute signalisation ?
>
> Merci, bonne soirée
>


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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir Deuzeffe,

Le lun. 16 déc. 2019 à 21:59, deuzeffe  a écrit :

>
> Si ma voix a un quelconque poids, elle ne s'y oppose pas.
>

C'est au contraire tout ce qui me manquait pour passer à l'action
Le wiki a déjà la nouvelle page :
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo

Le déplacement aura lieu d'ici fin décembre

Bonne soirée

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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[Brice]

Le 15/12/2019 à 17:32, Arnaud Champollion a écrit :
OK, et du coup serait-il cohérent de fusionner les bâtiments dès lors ceux ceux-ci constituent le même corps 
architectural ?


à mon avis non, autant rester cohérent au cadastre et conserver des corps de bâtiments séparés car des tags spécifiques* 
éventuellement ajoutés par la suite ne s'appliqueront bien qu'à un bâtiment en particulier.


* par exemple :
https://wiki.openstreetmap.org/wiki/Simple_3D_buildings

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

Re: [OSM-talk-fr] ref:FR:FANTOIR

[deuzeffe]

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

Bonjour,


Bonsoir,


1/ Tout d'abord, le "ref:FR:FANTOIR" doit être placé au niveau du
way ou de la relation ?


De la relation. On met sur la relation tout ce qui peut être
factorisé, donc le nom de voie (tag name=* dans la relation) et le
ref:FR:FANTOIR puisqu'il dépend du nom de voie.


Grmblbl, tu sais que, parfois, je te hais ?
--
deuzeffe - on verra plus tard :/

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

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[deuzeffe]

Le 17/12/2019 à 14:22, Quentin Salles a écrit :

Bonjour deauzeffe,

Rassure-moi : les arrêts en question sont bien dans une relation (avec
les voies) ie un trajet, elle-même dans la relation globale qui regroupe
tous les trajets ?
Oui l'ensemble des lignes se trouvent dans une relation "network"


Ouf ;) Donc, operator et network (dont "Tisséo") sur les relations 
(trajets + relation maître) devraient suffire à retrouver ce que tu 
cherches, non ?


Et comme je disais, je souhaitais ce changement de tag car d'autres 
réseaux l'ont fait. 


Certes. Je ne sais pas si c'est une bonne raison :P
--
deuzeffe

Après, je peux toujours faire un rétropédalage de la 
clé "ref"


Quentin SALLES

Le sam. 14 déc. 2019 à 11:43, deuzeffe > a écrit :


Le 13/12/2019 à 18:13, Quentin Salles a écrit :
 > Bonsoir,

Bonjour,

 > @deauzeffe Ce que tu dis est juste dans le cas où je cherche les
arrêts
 > de bus pour une ligne donnée.
 > Or dans ce que je disais, ça concernait l'ensemble des arrêts
desservis
 > par toutes les lignes du réseau Tisséo

Rassure-moi : les arrêts en question sont bien dans une relation (avec
les voies) ie un trajet, elle-même dans la relation globale qui
regroupe
tous les trajets ?

Pour ce que j'ai fait pour le réseau STCLM, j'avoue avoir été fainéante
et *ne pas avoir* taggué les références sur tous les arrêts.
Ça peut se faire, c'est juste que même si c'est une "petite" CU, il
y en
a whamille. Sans compter qu'il y a des arrêts desservis par plusieurs
réseau, et que oui, j'ai loupé cette étape. D'où ma préférence pour les
relations.

-- 
deuzeffe - partisane de l'effort optimal


 > Quentin SALLES
 >
 > Le ven. 13 déc. 2019 à 17:55, laurent-38
mailto:laurent.riffard%2bnab...@free.fr>
 > >> a écrit :
 >
 >     Frédéric Rodrigo-2 wrote
 >      > Le principe des règles, c'est de corrigé les données, pas
les règles.
 >      > La règle est valide et basé sur le wiki OSM.
 >      >
 >      > Le 10/12/2019 à 14:48, Quentin Salles a écrit :
 >      >> …
 >      >> Aujourd'hui, Osmose
 >      >> signale tous les arrêts de bus ayant un mauvais suffixe
 >     d'attribut sur
 >      >> la clé "ref:FR:Tisséo".
 >
 >     Bonjour Frédéric,
 >
 >     Peux-tu préciser le sens de ta réponse ?
 >
 >     S’agit-il de supprimer les accents dans les clés tels que
 >     ref:FR:Tisséo (ou
 >     ref:Transisère) ? Le wiki ne me semble pas l’interdire :
 > https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters
 >
 >     Ou bien s’agit-il d’enregistrer ces clés dans une « liste
blanche »,
 >     type
 >

https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales,
 >     pour qu’elles soient considérées comme correctes ?
 >
 >     Cordialement
 >     ~~
 >     laurent
 >
 >
 >
 >     --
 >     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
 >

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


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



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

[OSM-talk-fr] Fwd: [osm-grenoble] Projet Europeen de l'Eau/European Water Project - Introduction

[François Lacombe]

Bonsoir à tous,

Je relaye ici le message de Stuart qui a pris la peine de présenter ce
projet sur la liste local-grenoble.
Cela peut en intéresser certains

François

-- Forwarded message -
De : European Water Project 
Date: mar. 17 déc. 2019 à 10:57
Subject: [osm-grenoble] Projet Europeen de l'Eau/European Water Project -
Introduction
To: 


Bonjour,

Je m'appelle Stuart Rapoport. J'habite Divonne les Bain dans l'Ain.

Nous nous lançons dans un projet collaboratif qui est 100% Open Data et
utilise exclusiviement des données d'OpenStreetMap, Wikidata et Wikimedia
Commons. Notre toute nouvelle (et très petite) ONG Suisse  Projet Européen
de l'Eau (European Water Project) a but d'inciter les personnes de boire
l'eau du robinet et d’arrêter d’acheter des bouteilles à usage unique,
notamment celles en plastique.

J'ai écrit une Progressive Web Application en HTML5, CSS et Javascript que
vous pouvez télécharger sans passer par l'Apple Store ou le Google Store à
https://europeanwaterproject.org. Pour peupler les fontaines sur notre
carte, nous faisons tourner un script en nodejs qui extrait les données
d'OSM par l'API Overpass et  celles de Wikidata par l'API SPARQL.

Pour l'instant nous nous concentrons sur les fontaines d’eau potable en
Europe, mais nous voulons dans un deuxième temps participer dans le
développement d’un réseau de cafés et de restaurants qui sont d'accord pour
remplir des gourdes d'eau gratuitement pour toute personne qui le demande.

Nous présentons notre APP pour la première fois, le 8 janvier devant 860
étudiants de 48 pays.

Je voulais savoir si je pouvais venir le week-end du 15-16 février pendant
votre CA pour présenter rapidement notre projet ?

Je vous prie d'excuser mes fautes de français.

Cordialement,

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

Re: [OSM-talk-fr] Rendu transport routier...

[Philippe Verdy]

Le mar. 17 déc. 2019 à 20:36, Yves P.  a écrit :

>
> Et là aussi (sauf qu’il faut décharger 10t) :
> http://osm.cquest.org/fortissimo/#17/48.19065/3.31208
>

Seulement si le poids lourd passe de la route sortante à la rocade de
Sens... Si on reste sur la sortante Paris-Genève sans emprunter la rocade
de Sens (donc en passant au centre-ville), c'est 120t limite pour sortir du
centre-ville par là : il faudra donc sortir ailleurs (en passant par le
centre de Maillot, le sud de Malay-le-Grand, la route de Noé, etc.).

Ca a du sens mais il n'y a pas beaucoup de voies de grande capacité pour
les super-lourds.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu transport routier...

[pepilepi...@ovh.fr]

Le 17/12/2019 à 17:00, Christian Quest a écrit :
> Bug corrigé, halo passé en gris (rouge ça faisait "bouchons")
>
> *72 t*... *petit joueur*:
> http://osm.cquest.org/fortissimo/#14/48.1961/3.3036

C'est un concours à qui qu'a la plus grosse ?

Juste pour ma culture, quel est le poids maxi par défaut, c'est à dire
en l'absence de toute signalisation ?

Merci, bonne soirée

JP

>
> Le mar. 17 déc. 2019 à 16:36,  > a écrit :
>
>
> Bonjour
>
> Mais ici ( http://osm.cquest.org/fortissimo/#15/49.4170/0.2732 )
> ce n'est pas une aberration, mais bien réelle puisque c'est une
> voie utilisable par les transports exceptionnels
>
> Cordialement
> -- 
> David Crochet
>
> ___
> 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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question


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

Re: [OSM-talk-fr] Rendu transport routier...

[Yves P.]

> Bug corrigé, halo passé en gris (rouge ça faisait "bouchons »)
Ok, mais gris c’est à peine visible. Bleu ?

> 72t... petit joueur: http://osm.cquest.org/fortissimo/#14/48.1961/3.3036 
> 
Très fort aussi le segment XXXt à faire en zeppelin 😁
http://osm.cquest.org/fortissimo/#17/48.17649/3.36493
http://osm.cquest.org/fortissimo/#17/47.96591/3.38238

Et là aussi (sauf qu’il faut décharger 10t) :
http://osm.cquest.org/fortissimo/#17/48.19065/3.31208


Et aussi pour passer les ponts (ça sent le « bug »):
http://osm.cquest.org/fortissimo/#17/48.07671/3.29744
http://osm.cquest.org/fortissimo/#17/48.00348/3.32508
http://osm.cquest.org/fortissimo/#18/47.99605/3.32701
http://osm.cquest.org/fortissimo/#17/47.96813/3.39894
http://osm.cquest.org/fortissimo/#16/47.8560/3.5449

Et encore ici :
http://osm.cquest.org/fortissimo/#17/48.20358/3.31267
http://osm.cquest.org/fortissimo/#17/48.22421/3.29063
http://osm.cquest.org/fortissimo/#17/48.07671/3.29744

Il y a quoi dans le secteur, un sous traitant d’Ariane Espace ?

Et là, ça fait bizarre, en zoomant un peu on a la réponse :
http://osm.cquest.org/fortissimo/#14/48.2706/3.2931

Et enfin ici, il faut vider le camion ?
http://osm.cquest.org/fortissimo/#15/48.4029/3.2407
http://osm.cquest.org/fortissimo/#16/48.2349/3.6006
http://osm.cquest.org/fortissimo/#16/47.8492/3.5520
(c’est la fin de tes données de test ?)

Le rendu du fond est très lisible 😀

—
Yves

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

Re: [OSM-talk-fr] ref:FR:FANTOIR

[lenny.libre]

Bonsoir

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

Bonjour,


De: "Quentin Salles" 
2/ Que faire des voies qui ne comportent pas de rapprochement
OSM/Cadastre ?
http://cadastre.openstreetmap.fr/fantoir/#insee=31044&tab=0
Il vaudrait mieux que tu utilise la page 
https://dev.cadastre.openstreetmap.fr/fantoir/#insee=31044&tab=1

- Par exemple, sur le lien ci-dessus, "AV DU BICENTENAIRE 1789-1989"
est inscrit sur le fichier FANTOIR. Sur la commune, les plaques de
rue n'affiche que "AV DU BICENTENAIRE". Que faut-il choisir entre
les 2 ?



Dans OSM on privilégie le terrain, donc ici ça penche pour le choix 'Avenue du 
Bicentenaire'. Comme FANTOIR diverge, le fait d'ajouter le tag ref:FR:FANTOIR 
permettra de considérer dans BANO que 'Avenue du Bicentenaire' et 'AV DU 
BICENTENAIRE 1789-1989' sont la même voie. C'est la valeur du tag 
ref:FR:FANTOIR qui permettra le lien, car la comparaison des textes de nom de 
voie échouera.


D'ailleurs sur la page dev.cadastre.openstreetmap, on voit que "AV DU 
BICENTENAIRE 1789 1989" de FANTOIR a été rapprochée avec "Avenue du 
Bicentenaire" d'OSM


car le tag "ref:FR:FANTOIR" avait été saisi ; quand le rapprochement est 
fait automatiquement, le tag il est inutile.


cordialement

leni


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

Re: [OSM-talk-fr] Rendu transport routier...

[Christian Quest]

Bug corrigé, halo passé en gris (rouge ça faisait "bouchons")

72t... petit joueur: http://osm.cquest.org/fortissimo/#14/48.1961/3.3036

Le mar. 17 déc. 2019 à 16:36,  a écrit :

>
> Bonjour
>
> Mais ici ( http://osm.cquest.org/fortissimo/#15/49.4170/0.2732 ) ce n'est
> pas une aberration, mais bien réelle puisque c'est une voie utilisable par
> les transports exceptionnels
>
> Cordialement
> --
> David Crochet
>
> ___
> 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] ref:FR:FANTOIR

[Vincent de Château-Thierry]

Bonjour,

> De: "Quentin Salles" 
> 
> Je compte faire un peu de mis à jour sur ma commune au niveau des
> adresses et j'aimerai avoir des informations de votre part.
> 1/ Tout d'abord, le "ref:FR:FANTOIR" doit être placé au niveau du way
> ou de la relation ?

De la relation. On met sur la relation tout ce qui peut être factorisé, donc le 
nom de voie (tag name=* dans la relation) et le ref:FR:FANTOIR puisqu'il dépend 
du nom de voie.

> 2/ Que faire des voies qui ne comportent pas de rapprochement
> OSM/Cadastre ?
> http://cadastre.openstreetmap.fr/fantoir/#insee=31044&tab=0
> - Par exemple, sur le lien ci-dessus, "AV DU BICENTENAIRE 1789-1989"
> est inscrit sur le fichier FANTOIR. Sur la commune, les plaques de
> rue n'affiche que "AV DU BICENTENAIRE". Que faut-il choisir entre
> les 2 ?

Dans OSM on privilégie le terrain, donc ici ça penche pour le choix 'Avenue du 
Bicentenaire'. Comme FANTOIR diverge, le fait d'ajouter le tag ref:FR:FANTOIR 
permettra de considérer dans BANO que 'Avenue du Bicentenaire' et 'AV DU 
BICENTENAIRE 1789-1989' sont la même voie. C'est la valeur du tag 
ref:FR:FANTOIR qui permettra le lien, car la comparaison des textes de nom de 
voie échouera.

> - Que signifie "Ok" lorsqu'il n'y a pas de rapprochement avec OSM ?

Tu as une doc ici : 
https://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO#Interface_de_contr.C3.B4le_et_de_saisie_Fantoir.2FOSM
'Ok' est la valeur par défaut.

vincent

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

Re: [OSM-talk-fr] Rendu transport routier...

[david . crochet]

Bonjour

Mais ici ( http://osm.cquest.org/fortissimo/#15/49.4170/0.2732 ) ce n'est pas 
une aberration, mais bien réelle puisque c'est une voie utilisable par les 
transports exceptionnels

Cordialement
-- 
David Crochet

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

Re: [OSM-talk-fr] adresse mail rejetée

[Philippe Verdy]

Note: le 30 octobre j'ai arrêté d'utiliser l'adresse Wanadoo.fr mais
j'utilise l'adresse Gmail.com; cependant je suis toujours abonné aux deux
donc je peux recevoir (mais pas répondre forcément si je reçois encore des
messages par l'adresse historique Wanadoo.fr (qui n'a jamais cessé de
fonctionner depuis ~30 ans bien que j'ai changé plusieurs fois de FAI et de
régions; raison pour laquelle j'ai toutes mes anciennes adresses qui fon
ctionnent encore redirigées vers Gmail, que je peux lire aussi depuis
n'importe quel poste, même quand j'en change, ce que je ne pourrais pas
faire avec un client à stockage local type Thunderbird)

Mais je n'ai jamais utilisé le Webmail vraiment merdique de Wanadoo devenu
Orange dans le navigateur, car trop de pub et filtres de classement de
courrier trop limités, passoire aussi aux mails malveillants, et trop
d'anomalies sur leurs serveurs SMTP non standards lors de ses envois; le
Webmail d'Orange en plus ne protège pas des contenus HTML "actifs": cookies
traceurs, scripts, audio/vidéo, etc qui s'activent tout de suite dans la
boite de réception standard où presque tout passe, et les serveurs SMTP
d'Orange sont plein de trous de sécurité jamais corrigés, et pas tous
déclarés correctement dans les DNS et les certificats SSL!). Bref ma boite
Orange filtre un peu (presque rien) mais renvoie tout à Gmail qui est lui
bien plus efficace et bien plus pratique à utiliser.

Ca fait pas loin de 20 ans que je n'utilise plus les clients de courrier
locaux (POP3 ou IMAP) et je considère le stockage Gmail plus sur que sur
mon portable ou n'importe quel PC (je sais que Google peut indexer une
partie du contenu pour fournir un peu de pub, mais au moins ses pubs sont
vérifiées et pas trop gênantes, pas comme le mail de Crosoft (local ou
webmail) bourré d'arnaques et de pubs vraiment affligeantes: fake news en
pagaille, "blagues" stupides, spammeurs de tout bord qui vont vous harceler
au téléphone, et pubs vraiment gênantes pour la navigation ou même ma
consultation des mails au dessus desquels se superpose ces pubs
envahissantes; pire: le blocage de pub conduit vite à un blocage du
webmail, la composition de message est très erratiques, trop de messages
perdus en court de frappe, ça plante trop souvent, ou leurs serveurs sont
trop souvent en panne et perdent des données, et il n'y a aucune
authentification des émetteurs de messagers qu'on reçoit chez Orange, le
truc utilisant un système interne totalement propriétaire et invérifiable)
et la capacité de stockage cxhez Orange est beaucoup trop restreinte
(sature trop souvent à cause du volume de spams entrants: il vaut mieux
rediriger ailleurs, ça fait un double filtrage: en partie chez Orange,
l'autre chez Gmail, cela ajoute souvent même pas 10 secondes de délai pour
la réception des messages relayés, mais à priori je ne perds rien sauf si
la liste OSM.org reçoit un bounce d'Orange, ce qui arrive environ 1 ou 2
fois par mois mais finit par arriver quand même le lendemain ou dans la
semaine qui suit, parfois avec un entête ajouté dans le texte du mail par
Orange qui ne se préoccupe pas du tout de préserver l'intégrité des
messages avec au moins des pièces jointes conformes aux signatures
numériques).

Je note cependant que parfois il y a des bounces temporaires d'Orange vers
Gmail, mais le message finit par être remis, là encore avec un entête
supplémentaire (en gros 3 ou 4 par mois, pas plus, mais plus souvent pour
les mails envoyés par un expéditeur chez LaPoste)


Le lun. 16 déc. 2019 à 10:58, Jean-Claude Repetto  a
écrit :

> Le 16/12/2019 à 10:47, Francois Gouget a écrit :
> >
> > Concernant les emails de Philippe Verdy, pareil pour moi : je ne reçois
> > plus ses emails depuis le 2018-10-26. En fait je croyais qu'il avait
> > quitté la liste. Je n'ai pas regardé s'il y avait d'autres emails qui ne
> > me parviennent plus mais clairement il y a quelque chose qui n'est pas
> > normal là-dessous. Mais évidemment rien ne me permet de dire si ses
> > emails génèrent des bounces chez mon opérateur où si ça coince encore
> > avant : voir point 2 ci-dessus...
>
> Idem pour moi (je suis aussi chez Free): dernier message de P. Verdy
> reçu le 30/10/2018. Et j'ai encore été désabonné hier, pour la troisième
> fois en quelques jours.
>
> Jean-Claude
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


Le lun. 16 déc. 2019 à 10:58, Jean-Claude Repetto  a
écrit :

> Le 16/12/2019 à 10:47, Francois Gouget a écrit :
> >
> > Concernant les emails de Philippe Verdy, pareil pour moi : je ne reçois
> > plus ses emails depuis le 2018-10-26. En fait je croyais qu'il avait
> > quitté la liste. Je n'ai pas regardé s'il y avait d'autres emails qui ne
> > me parviennent plus mais clairement il y a quelque chose qui n'est pas
> > normal là-dessous. Mais évidemment rien ne me permet de dire si ses
> > emails génèrent des bounces chez mon opérateur où si ça coince

Re: [OSM-talk-fr] algorithme de calcul de la clé - Re: ref:FR:FANTOIR

[Philippe Verdy]

>
>
> Avez-vous des communes avec dir ≠ 0 ?
>

Oui: toutes les communes des 4 départements 75, 92, 59 et 13.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[Quentin Salles]

Bonjour deauzeffe,

Rassure-moi : les arrêts en question sont bien dans une relation (avec
les voies) ie un trajet, elle-même dans la relation globale qui regroupe
tous les trajets ?
Oui l'ensemble des lignes se trouvent dans une relation "network"

Et comme je disais, je souhaitais ce changement de tag car d'autres réseaux
l'ont fait. Après, je peux toujours faire un rétropédalage de la clé "ref"

Quentin SALLES

Le sam. 14 déc. 2019 à 11:43, deuzeffe  a écrit :

> Le 13/12/2019 à 18:13, Quentin Salles a écrit :
> > Bonsoir,
>
> Bonjour,
>
> > @deauzeffe Ce que tu dis est juste dans le cas où je cherche les arrêts
> > de bus pour une ligne donnée.
> > Or dans ce que je disais, ça concernait l'ensemble des arrêts desservis
> > par toutes les lignes du réseau Tisséo
>
> Rassure-moi : les arrêts en question sont bien dans une relation (avec
> les voies) ie un trajet, elle-même dans la relation globale qui regroupe
> tous les trajets ?
>
> Pour ce que j'ai fait pour le réseau STCLM, j'avoue avoir été fainéante
> et *ne pas avoir* taggué les références sur tous les arrêts.
> Ça peut se faire, c'est juste que même si c'est une "petite" CU, il y en
> a whamille. Sans compter qu'il y a des arrêts desservis par plusieurs
> réseau, et que oui, j'ai loupé cette étape. D'où ma préférence pour les
> relations.
>
> --
> deuzeffe - partisane de l'effort optimal
>
> > Quentin SALLES
> >
> > Le ven. 13 déc. 2019 à 17:55, laurent-38  > > a écrit :
> >
> > Frédéric Rodrigo-2 wrote
> >  > Le principe des règles, c'est de corrigé les données, pas les
> règles.
> >  > La règle est valide et basé sur le wiki OSM.
> >  >
> >  > Le 10/12/2019 à 14:48, Quentin Salles a écrit :
> >  >> …
> >  >> Aujourd'hui, Osmose
> >  >> signale tous les arrêts de bus ayant un mauvais suffixe
> > d'attribut sur
> >  >> la clé "ref:FR:Tisséo".
> >
> > Bonjour Frédéric,
> >
> > Peux-tu préciser le sens de ta réponse ?
> >
> > S’agit-il de supprimer les accents dans les clés tels que
> > ref:FR:Tisséo (ou
> > ref:Transisère) ? Le wiki ne me semble pas l’interdire :
> > https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters
> >
> > Ou bien s’agit-il d’enregistrer ces clés dans une « liste blanche »,
> > type
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> ,
> > pour qu’elles soient considérées comme correctes ?
> >
> > Cordialement
> > ~~
> > laurent
> >
> >
> >
> > --
> > 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
> >
>
> ___
> 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] ref:FR:FANTOIR

[Philippe Verdy]

Si on garde la clé c'est pour qu'elle soit vérifiable (et l'algo de calcul
est simplissime) et éviter les erreurs de saisie "à la volée". Ce qui
aurait mérité alors de garder le code division (là où il est encore utile
et non nul, donc pas dans les départements 75, 92, 59 et 13) : la
validation de la clé est alors immédiate et on repère immédiatement les
inversions de chiffres. Là on se contente juste d'un test de longueur, et
d'un controle à posteriori via le rapprochement BANO-OSM d'Osmose (ce qui
n'aide pas du tout les premiers contributeurs).

Ce serait donc bien de promouvoir ce contrôle à priori (dès la saisie ou
dans le validateur de données avant l'envoi à OSM) et non à posteriori
(d'autant qu'il y a encore des tas de lieux à référencer et rapprocher de
façon plus intelligente qu'un simple rapprochement de nom qui est bourré de
pièges). Ces références FANTOIR pourtant accélèrent considérablement à mon
avis les rapprochements et lèvent pas mal d'ambiguités, et fonctionnent
encore pour détecter les changements de noms et les expliquer.

Peut-être qu'on pourrait s'en sortir en délimitant les zones de direction
dans les 4 départements concernés, afin que la validation puisse déduire le
code manquant pour valider la clé. pour les autres départements on sait que
le code direction est 0, donc la validation est possible et à mon avis il
reste alors recommandé de garder la lettre clé finale dans les données OSM.

C'est une solution simple: 4 zones à créer pour Paris, 2 zones pour chacun
des 3 départements (à priori des communes entières, sauf si depuis des
communes ont fusionné entre deux zones à cheval, sans forcément changer les
codes FANTOIR qui risquent fort d'attendre encore 1 an ou plus avec leur
ancien code commune et leur ancien code direction).

Cela permettrait ensuite de faire le point avec la DGFIP pour que
finalement elle voit que les codes direction ne sont plus nécessaires et
peuvent être unifiés à "0" sans avoir même besoin de le préciser, quitte à
changer les lettres clés dans les 4 départements pour tenir compte du
changement implicite de code direction à 0, puis finalement même retirer ce
code direction obsolète du fichier FANTOIR de la DGFIP.

Et tant qu'à faire ce changement pour les 4 départements, rationaliser à
nouveau la typologie (les codes voie à 4 chiffres peuvent tous passer à 1
lettre plus 3 chiffres, puisque toutes les lettres ne sont pas utilisées).
LE code final en serait plus lisible sous la forme générale: 5 chiffres
(code commune)+1 lettre de type+3 chiffres (rang dans le type)+lettre clé
calculée sur les 9 premiers caractères (sans besoin de changer l'algo de
calcul qui reste simple: une substitution des lettres par un chiffres puis
un calcul similaire au LUHN, et un modulo mappé sur une lettre finale).

Ou bien tout en gardant 10 caractères, passer à un code avec  5 chiffres
(code commune)+2 lettres (type+sous-collection du type sans le 0, le I et
le L pour éviter la confusion avec les chiffres en ignorant la casse non
significative) +2 chiffres (rang dans le type+collection)+lettre clé (avec
un nouvel algo possible: une simple somme des chiffres, pondérés chacun par
plusieurs facteurs distincts 1,2,3,5,7,11,13,17,19 en fonction de leur
rang, puis un modulo égal à un autre nombre premier comme 23, conduisant à
mapper une clé d'une lettre parmi 23, sans le I et le O). Le sous-code
"collection" peut être utilisé pour les transitions millésimées dues aux
fusions/scissions de communes (on a le choix parmi les 23x23 lettres, quand
actuellement on n'utilise que les chiffres 00 à 99 et souvent beaucoup
moins, et 1 lettre parmi 3 suivi d'un chiffre parmi 9).

Au pire, on définit ça comme notre nouveau "code FANTOIR-OSM" remplaçant le
"code FANTOIR-RIVOLI" historique et capable aussi de représenter d'autres
champs du FANTOIR (exemple: public contre privé,
provisoire/chantier/projet/voie déclassée ou fermée mais qui pourrait être
reclassée à l'avenir). Et ce nouveau code n'a pas non plus obligation à
n'être que pour les communes si la compétence échoie à une agglomération ou
un département (dans ce cas on peut jouer sur les 5 premiers chiffres ou
lettres), ou à un grand gestionnaire foncier privé ou para-public (exemple:
agences de bassin, parcs naturels, portuaires/aéro-portuaire, armée,
forêts, zones internationales...)

Le lun. 16 déc. 2019 à 13:08, Vincent de Château-Thierry 
a écrit :

>
> > De: "Yves P." 
>
> > Concernant la clé de contrôle, est-ce nécessaire de la garder sachant
> > qu’il peut manquer le code div pour la recalculer ?
> > Si j’ai bien compris, tu as la base DGFiP complète sur un serveur et
> > un outil de contrôle qualité qui peut vérifier la cohérence entre
> > ref:FR:FANTOIR et les données brutes « FANTOIR ».
> > Du coup elle devient inutile ?
>
> Oui, le fichier FANTOIR est pris ici :
>
> https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/
> et fait partie intégrante du processus BANO, car cette longue liste est
> (sur le papier

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Quentin Salles]

Bonjour,

Je compte faire un peu de mis à jour sur ma commune au niveau des adresses
et j'aimerai avoir des informations de votre part.
1/ Tout d'abord, le "ref:FR:FANTOIR" doit être placé au niveau du way ou de
la relation ?
2/ Que faire des voies qui ne comportent pas de rapprochement OSM/Cadastre
? http://cadastre.openstreetmap.fr/fantoir/#insee=31044&tab=0
- Par exemple, sur le lien ci-dessus, "AV DU BICENTENAIRE 1789-1989" est
inscrit sur le fichier FANTOIR. Sur la commune, les plaques de rue
n'affiche que "AV DU BICENTENAIRE". Que faut-il choisir entre les 2 ?
- Que signifie "Ok" lorsqu'il n'y a pas de rapprochement avec OSM ?

Merci d'avance pour votre réponse.

Quentin

Le mar. 17 déc. 2019 à 12:14, Yves P.  a écrit :

> Bonjour,
>
> Suite du nettoyage.
>
> > Le 14 déc. 2019 à 12:37, Donat ROBAUX  a écrit :
>
> > */ref:FR:fantoir/. Sur celle de Brest, c'est le code voie qui est mis
> sur chaque adresse.
>
> J’ai regardé dans toutes les valeur de ref:FR:FANTOIR : il y en a 4395. On
> peut rajouter les 458 ref:FR:fantoir
>
> > ref:right:FR:FANTOIR doit être renommé en ref:FR:FANTOIR:right
> >
> > Ca j'ai corrigé
>
> Merci :)
>
> > Pour les /source:ref:fantoir/, je pense qu'on peut les enlever, ca
> n’apporte rien.
>
> C’est fait.
>
> —
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Orthos: mise à jour 2018 sur de nombreux départements

[Christian Quest]

La liste: 04 11 30 54 55 57 60 66 67 71 84 88 89

L'Oise (60) est disponible pour la première fois en opendata, ainsi que le
71 et 89 (depuis déjà plusieurs mois).

Tout ça est intégré dans 3 couches:
- orthohr_2018 : qui ne contient que les orthos de 2018
- orthohr : qui contient toutes les orthohr
- tous_fr : qui est combinaisons de toutes les orthos, en priorisant la
date puis la résolution

Vous avez le détail sur le wiki:
https://wiki.openstreetmap.org/wiki/FR:Serveurs/wms.openstreetmap.fr

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

Re: [OSM-talk-fr] ref:FR:FANTOIR

[Yves P.]

Bonjour,

Suite du nettoyage.

> Le 14 déc. 2019 à 12:37, Donat ROBAUX  a écrit :

> */ref:FR:fantoir/. Sur celle de Brest, c'est le code voie qui est mis sur 
> chaque adresse.

J’ai regardé dans toutes les valeur de ref:FR:FANTOIR : il y en a 4395. On peut 
rajouter les 458 ref:FR:fantoir

> ref:right:FR:FANTOIR doit être renommé en ref:FR:FANTOIR:right
> 
> Ca j'ai corrigé

Merci :)

> Pour les /source:ref:fantoir/, je pense qu'on peut les enlever, ca n’apporte 
> rien.

C’est fait.

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

Re: [OSM-talk-fr] Rendu transport routier...

[Philippe Verdy]

Les limites de tonnage variables selon le sens sont probablement erronées
(sauf en cas de tabliers séparés sur les ponts, mais alors on a deux ways
et non un seul. Sur les routes même avec des accotements déstabilisés, je
vois mal une mairie ou un département prendre le risque d'un dépassement
(parfois inévitable en cas d'obstruction) sur l'autre côté de la route
causant un effondrement ou un affaissement sans prévoir alors une
séparation des voies.

En revanche les limites de hauteur selon le côté de la route sont possibles
si le tablier au dessus traverse en oblique ou s'il y a des éléments
suspendus d'un seul côté. De même les restrictions de largeur en cas de
chaussées séparées 2+1 (le sens à 1 voie pouvant être trop étroit alors que
le sens à 2 voies peut encore permettre un passage même en occupant une
partie de la seconde voie).

Ca c'est la théorie, reste à voir si ça se trouve réellement (les voies 2+1
sont de plus en plus rares, remplacées par 1+1 voie et une bande centrale
étroite de chaque côté permettant juste un écart exceptionnel à vitesse
réduite, juste condamnée par un zébrage, ou réutilisée pour créer une bande
cyclable centrale à double sens ou une bande latérale dans chaque sens, ou
une réserve pour la sécurité des piétons.passant un tunnel sous un pont.

Mais la cartographie est pleine d'exceptions locales à ce qui semblerait
être la "norme"...


Le mar. 17 déc. 2019 à 10:34, Eric SIBERT via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> >> - restriction dans un seul sens?
> >
> > En ajoutant une flèche sur le halo rouge ?
>
> Non car je vois venir le cas de restrictions différentes dans les deux
> sens ;-)
> 10 T à la montée, 3,5T à la descente...
>
> Une flèche derrière le panneau?
>
> Eric
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu transport routier...

[Christian Quest]

Petit bug de ma part... je vais corriger ça ;)


Le mar. 17 déc. 2019 à 10:32, Donat ROBAUX  a écrit :

> Bon le message est parti un peu vite...
>
> Pour le pont de Châtillon-Montouge, les données sont bonnes et conformes au
> wiki avec le séparateur qui doit être un point.
> Donc il y a un bug dans la retranscription de la donnée.
> Idem ici, c'est encore plus flagrant avec 2 valeurs 5.07 et 4.57m qui
> apparaissent en 57m et 4.57m:
> http://osm.cquest.org/fortissimo/#18/48.81966/2.29577
>
> 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
>


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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[Vincent Bergeot]

Le 17/12/2019 à 08:00, Arnaud Champollion a écrit :

Le 17/12/2019 à 06:19, Vincent Bergeot a écrit :
j'aime landuse=school (pour l'ensemble scolaire) mais l'usage semble 
aller vers amenity=school, building=school et j'ajoute des poi pour 
amenity=school et school:FR=*, car même si maternelle et élémentaire 
sont dans un même lieu, c'est souvent distinct (entrée différente, 
cours de récréation et jeux adaptés, ...)


avec des redondances (ref uai, adresse, ...) 


Mais du coup ça crée plusieurs amenity=school pour une seule entité.

Si par exemple on fait une requête overpass (par exemple pour obtenir 
les écoles du département et les afficher sur Umap) on ne risque pas 
de se retrouver avec des doublons ?


oui et cela dépendra de la requête, du type d'écoles attendues. school, 
school:FR, ...


[amenity=school][school:FR=élémentaire] ne renvoie normalement pas de 
doublons dans le cas évoqué


De plus comme le précise @cquest par ailleurs, landuse=school est un peu 
franco-français, voire franco-allemande j'ai l'impression : 
https://taginfo.openstreetmap.org/tags/landuse=school#map


à plus


--
Vincent Bergeot


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

Re: [OSM-talk-fr] Rendu transport routier...

[Eric SIBERT via Talk-fr]

- restriction dans un seul sens?


En ajoutant une flèche sur le halo rouge ?


Non car je vois venir le cas de restrictions différentes dans les deux 
sens ;-)

10 T à la montée, 3,5T à la descente...

Une flèche derrière le panneau?

Eric


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

Re: [OSM-talk-fr] Rendu transport routier...

[Donat ROBAUX]

Bon le message est parti un peu vite...

Pour le pont de Châtillon-Montouge, les données sont bonnes et conformes au
wiki avec le séparateur qui doit être un point.
Donc il y a un bug dans la retranscription de la donnée.
Idem ici, c'est encore plus flagrant avec 2 valeurs 5.07 et 4.57m qui
apparaissent en 57m et 4.57m:
http://osm.cquest.org/fortissimo/#18/48.81966/2.29577

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] Rendu transport routier...

[Francescu GAROBY]

65m. de haut ? Ah oui, c'est bien : vous prévoyez large, par chez vous !

Le mar. 17 déc. 2019 à 10:21, Donat ROBAUX  a écrit :

> Pour la bizarrerie, je n'ai pas eu besoin d'aller loin de chez moi.
> http://osm.cquest.org/fortissimo/#17/48.81215/2.30086
>
> Mais que fait OSMontrouge?
>
> 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
>


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

Re: [OSM-talk-fr] Rendu transport routier...

[Donat ROBAUX]

Pour la bizarrerie, je n'ai pas eu besoin d'aller loin de chez moi.
http://osm.cquest.org/fortissimo/#17/48.81215/2.30086

Mais que fait OSMontrouge? 

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] Rendu transport routier...

[Christian Quest]

Le lun. 16 déc. 2019 à 19:45, Eric SIBERT  a
écrit :

> Je viens de regarder. Quelques remarques:
> - maxwidth/maxheight : on ne voit pas bien les petites pointes autour de
> la valeur et on a du mal à distinguer les deux limitations.
>

Je vais améliorer les SVG des panneaux pour que ça soit plus visible.


> - double-restriction (maxweight = 3.5 et maxwidth = 2.2 par exemple). On
> ne voit que le maxweight.
>

Oui, ça, difficile à gérer sur le rendu, il faudrait des panneaux côte à
côté... pas simple au niveau cartocss.


> - restriction dans un seul sens? (la côte de Laffrey :
>
https://www.openstreetmap.org/#map=15/45.0344/5.7682
> https://fr.wikipedia.org/wiki/Rampe_de_Laffrey )
>
>
En ajoutant une flèche sur le halo rouge ?



> > Je découvre du coup de valeurs pas très catholiques dans ces tags !
>
> Des exemples, des exemples !!!
>
>
J'ai trouvé des valeurs multiples (avec ;), des valeurs en "4.00" (que je
nettoie), des unités présentes alors qu'on est en métrique, des valeurs
textuelles (filtrées), etc...


> Comme quoi, dès qu'on rend visible certaines données OSM...
>
> On ne taggue pas pour le rendu... mais ça aide ;-).
>
> Eric
>

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

Re: [OSM-talk-fr] Rendu transport routier...

[Christian Quest]

Hum... l'idée est de qualifier les voies visibles sur le fond. C'est au
fond de montrer que c'est en souterrain.

Au final, ces voies (en souterrain ou pas) ont des restrictions de
gabarits... ce qu'on montre avec l'overlay.

Le lun. 16 déc. 2019 à 17:59, Francescu GAROBY  a
écrit :

> Beau boulot !
> Une petite suggestion, tout de même : différencier les limitations de
> hauteur en surface, et celles en sous-sol.
> Exemple ici  : la
> limitation à 2,2m de haut concerne le parking souterrain du Leclerc.
>
>
> Francescu
>
> Le sam. 14 déc. 2019 à 18:30, Christian Quest  a
> écrit :
>
>> Je travaille depuis quelques temps sur un rendu destiné au transport
>> routier.
>>
>> Je finalise une couche en overlay qui rend visible les restrictions:
>> - maxheight
>> - maxweight
>> - maxwidth
>> - hgv/goods
>> - hazmat
>>
>> Voici ce que ça donne:
>> http://osm.cquest.org/fortissimo/#15/48.8324/2.3837
>>
>> Je découvre du coup de valeurs pas très catholiques dans ces tags !
>> Comme quoi, dès qu'on rend visible certaines données OSM...
>>
>> Le fond est une variation du style pianoforte (de ybon) qui comporte plus
>> d'éléments visibles et fait ressortir aussi les zones industrielles,
>> commerciales, chantiers. Son petit nom: fortissimo
>>
>> Merci pour vos retours !
>> --
>> Christian Quest - OpenStreetMap France
>> ___
>> 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
>


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

Re: [OSM-talk-fr] Re: Nommage des bâtiments scolaires / universitaires complexes

[Christian Quest]

Attention, landuse=school est une bizarerie franco-française qui nous a
servit à décrire les groupes scolaires où l'on est incapable de dire quelle
partie correspond à quelle école (maternelle, élémentaire, etc).

Il est rendu sur le rendu FR, mais pas ailleurs à ce que je sache.


Le lun. 16 déc. 2019 à 04:58, Adrien André via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Le 19-12-15 à 09 h 18, Adrien André via Talk-fr a écrit :
> > À ce sujet, j'ai remarqué qu'osm-carto ne rend pas les polygones
> > landuse=school.
> Par exemple, https://www.openstreetmap.org/way/687225350
>

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