Re: [OSM-talk-fr] Le bourg d'une commune

[Rpnpif via Talk-fr]

Le 03/12/2020 à 23:49, osm.sanspourr...@spamgourmet.com a écrit :


Le 03/12/2020 à 21:55, deuzeffe - opensm@deuzeffe.org a écrit :

Le 03/12/2020 à 11:04, Rpnpif via Talk-fr a écrit :

Bonsoir,


À Nantes, on a bien le Lieu unique ;) qui devrait être un nom commun.


Si tu es Nantais, tu sais bien que /Le Lieu Unique/ est bien un nom
propre (name=), comme le dit ades, (avec une évocation du passé du
lieu dans lequel il est installé...)


Tu veux dite le lieu unique (https://www.lelieuunique.com/,
https://fr.wikipedia.org/wiki/Le_Lieu_unique).

Et oui ils ont mit tout en minuscules.

Dans OSM 3 majuscules mais l'arrêt de bus n'a pas d'article.

https://www.openstreetmap.org/search?query=le%20lieu%20unique#map=19/47.21529/-1.54560 



Oui vous avez bien LU.

Le 03/12/2020 à 11:04, Rpnpif via Talk-fr - talk-fr@openstreetmap.org a
écrit :


Mon propre nom en a subi les conséquences.


C'est vrai que Rpnpif ;-).

Je ne sais qui dans le Lot a eu l'idée d'appeler une commune le bourg
https://fr.wikipedia.org/wiki/Le_Bourg

Mais sinon les bourgs sont des dénominations génériques signifiant le
centre aggloméré de la commune.

Après il y a des dénominations spécifiques, au bourg de Guidel ils ont
bien réussi à faire un "Villeneuve le Bourg"

https://www.mapillary.com/app/?lat=47.791543=-3.4902096=17=CrtrlHno_7alPyfFePQ6yg=photo=0.2556606449554435=0.5015682081004983=2 


Oui c'est une impasse ! Qui est 3 fois dans FANTOIR : lieu-dit (en
double) et voie sans adresses (1 entreprise de taxi). Dans OSM il y le
voisinage, pas la rue car il n'y pas de plaque de rue mais juste en
direction en début d'impasse. Devrait-on ajouter un noname=yes ? Je me
suis contenté de mettre la ref FANTOIR.

Jean-Yvon 


Le « lieu unique » c'était une petite provocation ;) pour montrer que 
les choses ne sont pas binaires.


Sinon je suis d'accord avec ce qu'écrit Christian Rogel dans le fil.

--
Rpnpif

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

Re: [OSM-talk-fr] Le bourg d'une commune

[Rpnpif via Talk-fr]

Bonjour,

Le 01/12/2020 à 11:36, Marc_marc a écrit :

Le 01.12.20 à 11:27, Christian Rogel a écrit :

Dire que bourg n’est pas un lieu-dit utilisé
est une affirmation non étayée

que je n'ai pas dis...

bureau de poste, banque, mairie, bourg, tout cela sont des noms de
lieux, mais ce sont des noms *communs* d'une *catégorie* de lieu et
non des noms propres désignant un lieu précis.
catégorie -> tag style amnity=townhall place=*
nom propre -> name


Ce n'est pas toujours un nom commun mais le véritable nom d'un simple 
lieu-dit ou bien de l'agglomération dans un ensemble plus vaste du nom 
de la commune. Les exemples existent mais je ne peux les trouver à la 
minute.


Je pense qu'il ne faut pas être rigide dans ce domaine comme le sont 
certains employés de l'État civil qui plaquent leurs idées reçues sur 
les noms propres de personnes ou de lieux-dits à l'origine de nombreuses 
erreurs par rapport à la réalité.
Mon propre nom en a subi les conséquences. Cela tue la créativité du 
simple citoyen et le dépossède de son histoire ou de l'histoire du lieu, 
si on veut philosopher.


Certains maires se sentent même obligés de débaptiser des lieux pour 
aller vers un consensus de soi-disant bon sens.


À Nantes, on a bien le Lieu unique ;) qui devrait être un nom commun.

--
Rpnpif


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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Rpnpif via Talk-fr]

Le 24/11/2020 à 20:37, Jean-Marc Liotier a écrit :

On 11/24/20 6:22 PM, Frédéric Rodrigo wrote:
Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il 
est nécessaire d'écrire des adaptateurs pour chaque langue ou pays 
pour traiter les particularités.


Je découvre donc:

- La phonemicization: 
https://github.com/addok/addok-fr/blob/master/addok_fr/utils.py


- Les particularités Françaises: 
https://github.com/addok/addok-france/blob/master/addok_france/utils.py


On comprend vite qu'il sera compliqué d'accepter une recherche sans 
connaître dans quel zone administrative et linguistique elle s'inscrit...


La « phonemicization » ressemble à une sorte de phonétisation 
simplifiée, non ?


Pourquoi n'avoir pas pris de bibliothèques de phonétisation qui sont 
beaucoup plus complètes et plus adaptables à la zone de recherche, comme 
celles des moteurs de recherche ?

Trop lourdes ?

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

Re: [OSM-talk-fr] JOSM version stable 17329 : traduction du Journal des modifications

[Rpnpif via Talk-fr]

Le 24/11/2020 à 08:07, Cyrille37 OSM via Talk-fr a écrit :

Bonjour

et Mille mercis et bravo pour ce super logiciel que vous savez 
maintenir toutes ces années.


+1.

Dommage qu'il ne gère pas bien le HiDpi (haute résolution d'écran) sous 
Linux (probablement du fait des bibliothèques de Java). Mais un ticket 
est en cours. Donc espoir.


--
Rpnpif

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

Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

[Rpnpif via Talk-fr]

Le 13/11/2020 à 10:16, Vincent de Château-Thierry a écrit :

Bonjour,


De: "Christian Quest" 

Certes, mais ce n'est pas ce que dit le wiki (intl) et ce n'est pas
globalement la pratique, sauf en France. Séparatisme ? ;)

Le wiki est un wiki :) On doit pouvoir y indiquer comment ça fonctionne en 
France, tout simplement.
Quand je vois les combinaisons du tag population sur Taginfo [1] on a plus de 10 
"admin_level=*" et plus de 10 "boundary=*". Donc c'est loin d'être 
franco-français.

vincent

[1] https://taginfo.openstreetmap.org/keys/population#combinations


Bonjour,

Attention aussi, certains admin-centre ne sont pas sur le village ayant 
la plus grande population, donc c'est une mauvaise idée de mettre en 
relief l'admin-centre avec ce critère. Par ailleurs, on attend toujours 
l'affichage des noms des communes nouvelles qui devrait se faire avant 
les anciennes communes membres.


--
Rpnpif


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

Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

[Rpnpif via Talk-fr]

Merci à vous tous !

--
Rpnpif

Le 11/11/2020 à 16:34, Christian Quest a écrit :
Il y a sûrement des ajustements à faire, liés à la nouvelle 
organisation des données et aux nouvelles sources.


Beaucoup de rouge nouveau semble concerner des points adresse liés à 
des noms de lieux-dits qu'il ne me semble pas avoir vu avant, ou au 
moins pas aussi souvent.



Là, la base PG est en cours d'upgrade, donc un peu de patience pour 
que ça revienne ;)



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

Re: [OSM-talk-fr] Test tuiles vecto sur ProjetDuMois.fr

[Rpnpif via Talk-fr]

Oups non, j'avais mal vu : le défibrillateur est marqué à intégrer alors 
qu'il l'est déjà mais à 5 ou 10 m plus loin.


--
Rpnpif

Le 19/10/2020 à 11:52, Rpnpif via Talk-fr a écrit :


Bonjour,

Initiative intéressante d'utiliser des tuiles vectorielles. Mais je 
note qu'elles ne sont pas à jour : je viens de commenter par erreur un 
défibrillateur qui avait été supprimé et replacé plus loin.


Quel est le délai de mise à jour de ces tuiles ?

--
Rpnpif

Le 18/10/2020 à 13:15, Florian LAINEZ a écrit :

Hello,
On vient de passer aux tuiles vectorielles pour le fond de carte de 
projetdumois.fr <http://projetdumois.fr>
Est-ce que ce fond de carte vous paraît pertinent pour les /projets 
du mois /? Manque-t-il des éléments ? La vitesse de chargement 
est-elle bonne ? ...
Votre avis/retour est le bienvenu sur 
https://github.com/vdct/ProjetDuMois/issues 
<https://github.com/vdct/ProjetDuMois/issues>


Grâce au boulot d'Adrien Pavie et de Frédéric Rodrigo (merci les gars 
!), /projet du mois/ est le premier service qui bénéficie de tuiles 
vectorielles hébergées par l'asso.
Si ça marche bien, on envisage donc d'en étendre l'usage à d'autres 
services.

Merci par avance pour vos retour

--

*Florian Lainez*

@overflorian <http://twitter.com/overflorian>

___
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] Test tuiles vecto sur ProjetDuMois.fr

[Rpnpif via Talk-fr]

Bonjour,

Initiative intéressante d'utiliser des tuiles vectorielles. Mais je note 
qu'elles ne sont pas à jour : je viens de commenter par erreur un 
défibrillateur qui avait été supprimé et replacé plus loin.


Quel est le délai de mise à jour de ces tuiles ?

--
Rpnpif

Le 18/10/2020 à 13:15, Florian LAINEZ a écrit :

Hello,
On vient de passer aux tuiles vectorielles pour le fond de carte de 
projetdumois.fr 
Est-ce que ce fond de carte vous paraît pertinent pour les /projets du 
mois /? Manque-t-il des éléments ? La vitesse de chargement est-elle 
bonne ? ...
Votre avis/retour est le bienvenu sur 
https://github.com/vdct/ProjetDuMois/issues 



Grâce au boulot d'Adrien Pavie et de Frédéric Rodrigo (merci les gars 
!), /projet du mois/ est le premier service qui bénéficie de tuiles 
vectorielles hébergées par l'asso.
Si ça marche bien, on envisage donc d'en étendre l'usage à d'autres 
services.

Merci par avance pour vos retour

--

*Florian Lainez*

@overflorian 

___
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] Erreurs 500 sur OrthoHR

[Rpnpif via Talk-fr]

Impeccable ! Merci beaucoup Christian.

Il ne me reste plus qu'à faire un ticket pour JOSM qui gère mal les 
erreurs de serveurs.


--
Rpnpif

Le 13/10/2020 à 16:39, Christian Quest a écrit :


Oups, un vilain effet de bord !

C'est réparé :)


Les requêtes répétées quand il y a une erreur c'est effectivement pas 
l'idéal.



Le 13/10/2020 à 16:22, Rpnpif via Talk-fr a écrit :

Le 13/10/2020 à 16:16, Rpnpif a écrit :

Bonjour,

Depuis deux jours l'OrthoHR ne marche plus sauf en définition très 
pixélisée.


J'ai des milliers de :

2020-10-13 16:13:06.770 INFOS: GET 
https://wms.openstreetmap.fr/tms/1.0.0/orthohr/21/1042880/732339 -> 
HTTP/1.1 500 (87 ms)


sous JOSM et ça mouline avec un CPU à 117% (2 cœurs).

OrthoHR est en panne et JOSM n'aime pas du tout. Il devrait arrêter 
de charger quand il y a trop d'erreurs, non ?



Voici le message d'erreur :

An error occurred: msDrawMap(): Image handling error. Failed to draw layer 
named 'orthohr_2013'.
msDrawRasterLayerLow(): Unable to access file. Corrupt, empty or missing file 
'/data/work/wms/orthohr/tileindex/2013/ORTHOHR_1-0_RVB-0M20_JP2-E080_LAMB93_D049_2013-01-01/49-2013-0400-6735-LA93-0M20-E080.gpkg'
 for layer 'orthohr_2013'. 
/data/work/wms/orthohr/tileindex/2013/ORTHOHR_1-0_RVB-0M20_JP2-E080_LAMB93_D049_2013-01-01/49-2013-0400-6735-LA93-0M20-E080.gpkg:
 No such file or directory
   File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line 
258, in modPythonHandler
 host )
   File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line 
210, in dispatchRequest
 return self.renderTile(tile, params.has_key('FORCE'))
   File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line 
140, in renderTile
 data = layer.render(tile, force=force)
   File "/usr/local/lib/python2.7/dist-packages/TileCache/Layer.py", line 444, 
in render
 return self.renderTile(tile)
   File "/usr/local/lib/python2.7/dist-packages/TileCache/Layers/MapServer.py", 
line 51, in renderTile
 mapImage = wms.draw()
   File "/usr/lib/python2.7/dist-packages/mapscript.py", line 2619, in draw
 return _mapscript.mapObj_draw(self)
--
Rpnpif

--
Ce message a été vérifié par *MailScanner* 
<http://www.mailscanner.info/>

pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

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

--
Christian Quest - OpenStreetMap France

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


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

Re: [OSM-talk-fr] Erreurs 500 sur OrthoHR

[Rpnpif via Talk-fr]

Le 13/10/2020 à 16:16, Rpnpif a écrit :

Bonjour,

Depuis deux jours l'OrthoHR ne marche plus sauf en définition très 
pixélisée.


J'ai des milliers de :

2020-10-13 16:13:06.770 INFOS: GET 
https://wms.openstreetmap.fr/tms/1.0.0/orthohr/21/1042880/732339 -> 
HTTP/1.1 500 (87 ms)


sous JOSM et ça mouline avec un CPU à 117% (2 cœurs).

OrthoHR est en panne et JOSM n'aime pas du tout. Il devrait arrêter de 
charger quand il y a trop d'erreurs, non ?



Voici le message d'erreur :

An error occurred: msDrawMap(): Image handling error. Failed to draw layer 
named 'orthohr_2013'.
msDrawRasterLayerLow(): Unable to access file. Corrupt, empty or missing file 
'/data/work/wms/orthohr/tileindex/2013/ORTHOHR_1-0_RVB-0M20_JP2-E080_LAMB93_D049_2013-01-01/49-2013-0400-6735-LA93-0M20-E080.gpkg'
 for layer 'orthohr_2013'. 
/data/work/wms/orthohr/tileindex/2013/ORTHOHR_1-0_RVB-0M20_JP2-E080_LAMB93_D049_2013-01-01/49-2013-0400-6735-LA93-0M20-E080.gpkg:
 No such file or directory
  File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line 258, 
in modPythonHandler
host )
  File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line 210, 
in dispatchRequest
return self.renderTile(tile, params.has_key('FORCE'))
  File "/usr/local/lib/python2.7/dist-packages/TileCache/Service.py", line 140, 
in renderTile
data = layer.render(tile, force=force)
  File "/usr/local/lib/python2.7/dist-packages/TileCache/Layer.py", line 444, 
in render
return self.renderTile(tile)
  File "/usr/local/lib/python2.7/dist-packages/TileCache/Layers/MapServer.py", 
line 51, in renderTile
mapImage = wms.draw()
  File "/usr/lib/python2.7/dist-packages/mapscript.py", line 2619, in draw
return _mapscript.mapObj_draw(self)

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

[OSM-talk-fr] Erreurs 500 sur OrthoHR

[Rpnpif via Talk-fr]

Bonjour,

Depuis deux jours l'OrthoHR ne marche plus sauf en définition très 
pixélisée.


J'ai des milliers de :

2020-10-13 16:13:06.770 INFOS: GET 
https://wms.openstreetmap.fr/tms/1.0.0/orthohr/21/1042880/732339 -> 
HTTP/1.1 500 (87 ms)


sous JOSM et ça mouline avec un CPU à 117% (2 cœurs).

OrthoHR est en panne et JOSM n'aime pas du tout. Il devrait arrêter de 
charger quand il y a trop d'erreurs, non ?


--
Rpnpif

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

Re: [OSM-talk-fr] JOSM version stable 17084 : Correction des fuites de mémoire

[Rpnpif via Talk-fr]

Le 13/10/2020 à 13:36, Yves P. a écrit :
Ca se règle dans les paramètres de la VM: la garbage collector ne 
tourne pas aussi souvent que tu le crois, on peut lui demander de 
tourner plus souvent.
Certes, mais il met semble que ma bécane ne rebootait pas toute seule 
avant avec JOSM.


Depuis la mise à jour, c'est pire.

De plus tu peux lancer JOSM en activant la console, et tu as le 
moyen de lancer le garbage collector à la main pour le forcer à faire 
un cycle complet de finalisation et de libération.

Est-ce que ça suffira ?

Je pensais que les fuites de mémoire n'apparaissaient pas dans les 
applications JAVA à cause de la "balayette", mais non :


/Java does automatic Garbage collection./
/However there can be situations where garbage collector does not
collect objects because there are references to them. /
Source 


Bonjour,

J'ai aussi le problème de consommation de mémoire. Je ne sais pas si 
c'est ça qui me fait une erreur non fatale sous Debian Linux après 
quelques minutes de travail quand j'utilise les listes d'attributs ou 
les listes de leurs valeurs. Je l'ai aussi quand j'utilise la liste de 
l'historique des sources quand j'envoie les données. C'est pénible.


J'ai fait un ticket.

--

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

[OSM-talk-fr] Couche d'affichage des noms de lieux-dits et frontières sur une photo satellite avec Leaflet

[Rpnpif via Talk-fr]

Bonjour,

J'aurais besoin de savoir quelle adresse vous me suggérez pour obtenir 
seulement les lieux-dits et éventuellement (et ultérieurement les routes 
et les frontières -- boundaries) afin de les afficher en surimpression 
sur une photo satellite ESRI comme le fait Id.


Je sais faire un extrait d'overpass.de et l'afficher sur la photo mais 
j'aurais préféré avoir des mises à jour en temps quasi réel en vectoriel 
bien sûr si possible. Le trafic serait assez faible.


Auriez-vous des idées d'adresses de données ou des exemples ?

Cordialement.

--
Rpnpif

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

Re: [OSM-talk-fr] maxspeed par défaut

[Rpnpif via Talk-fr]

Le 03/09/2020 à 16:41, osm.sanspourr...@spamgourmet.com a écrit :

Quel intérêt de rappeler un doublon désuet ?

Sauf à rappeler que c'est doublon désuet.


maxspeed:type désuet ? La page de wiki de source:maxspeed a été créée en 
2009, celle de maxspeed:type en 2011.


C'est vrai que source:maxspeed est le plus utilisé avec 1,6 millions de 
valeurs alors que maxspeed:type en a 378000 ce qui n'est pas ridicule.


Je connais la discussion sur ce sujet mais pour être exhaustif, il 
fallait citer les deux. D'ailleurs c'est ce que fait la page en anglais 
du wiki sans prendre parti.


Personnellement, j'ai un léger faible pour maxspeed:type car ce n'est 
pas véritablement une source mais plutôt une référence remplaçable par 
une valeur. Les applications qui utilisent la carte, n'utilisent que 
rarement les attributs source:* alors que la valeur FR:urban peut être 
remplacée par une vitesse.

Cela n'a rien a voir avec source=cadastre ou autre.

Mais je ne suis pas intégriste de cet attribut mais je pense qu'il faut 
laisser le choix vu le nombre d'utilisation.


--
Rpnpif

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

Re: [OSM-talk-fr] Rond point et relations routes

[Rpnpif via Talk-fr]

Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit :

Bonjour,

J'ai souvent découpé des giratoires pour des lignes de bus : honte sur 
moi !

Promis, je ne le ferai plus ;-)

Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs 
comme moi, dans des pages comme https://wiki.openstreetmap.org/wiki/FR:Bus
ou 
https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points 
?


Je ne maîtrise pas assez celles-ci pour m'amuser à modifier le wiki 
moi-même. Et il semblerait qu'il n'y ait pas consensus...
Peut-on écrire par ci par là que la bonne pratique en France est de, 
si possible, ne pas casser les rond points en plusieurs segments ?



+1 ! Tout à fait d'accord.

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

Re: [OSM-talk-fr] maxspeed par défaut

[Rpnpif via Talk-fr]

Bonjour,

Le 03/09/2020 à 03:38, Marc Mongenet a écrit :

Le mer. 2 sept. 2020 à 01:16, Yannick  a écrit :

L'implicite est désormais quasi impossible à deviner.
Je suis donc partisan de mettre systématiquement le maxspeed=* au
moins c'est clairement renseigné sans équivoque possible.

Oui l'implicite est difficile à maîtriser. Mais le problème que j'ai
rencontré, et je pense qu'il est répandu, c'est que les mappeurs ne
connaissent pas suffisamment bien le code de la route pour expliciter
correctement l'implicite! D'ailleurs, en relisant les textes
réglementaires avant de poster, je me suis rendu compte que je ne suis
pas tout à fait au clair moi-même.

Ainsi, je pense que
https://wiki.openstreetmap.org/wiki/FR:Key:maxspeed#Limitation_de_vitesse
se trompe en écrivant:


Et comme ce serait trop simple, je rappelle qu'il existe aussi 
maxspeed:type comme synonyme de source:maxspeed. Le premier est oublié 
sur le wiki en français.


--
Rpnpif

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

Re: [OSM-talk-fr] Renseigner un « Lieu-dit »

[Rpnpif via Talk-fr]

Bonjour,

Le 16/08/2020 à 19:19, Jacques Lavignotte a écrit :
Je regarde le Wiki et je vois que ça peut-être "place" ou "hamlet" si 
habité.


Mais ceci :

https://www.openstreetmap.org/way/157107477#map=15/45.1635/-0.1552

me semble très discutable...


Qu'en penser ?

J.


Mettre le nom du lieu-dit comme nom d'une voie est très fréquent. 
Geoportail (IGN) le fait souvent sur ses cartes.


Effet de bord : Cela facilite beaucoup l'affectation du nom du lieu-dit 
à la numérotation des maisons sous JOSM ou Id.


Ensuite, est-ce une pratique souhaitable ? Ça se discute. L'avantage est 
de donner un nom à la voie ou portion de voie sous-jacente qui sinon 
serait souvent anonyme.


Personnellement, je ne trouve pas gênant de le faire. Ce n'est pas le 
facteur (surtout en cette période de remplacement) qui me contredira.


Ce qui n'empêche pas effectivement d'ajouter aussi des place=*.

.--

Rpnpif

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

Re: [OSM-talk-fr] Rendu OSM et fusion de communes

[Rpnpif via Talk-fr]

Ma réponse dans le texte.

Le 29/05/2020 à 08:15, Philippe Verdy a écrit :
Ce n'est pas exact: si les noeuds représentent les place=* pour les 
noms locaux, les noms des relations sont visibles le long des 
frontières (il suffit de zoomer pour les voir). si on dézoome, le 
noeud va être trop petit par rapport à la relation, et la relation 
prend le pas, masquant le noeud représentant une relation plus petite 
quand on ne peut pas afficher les deux.


D'abord je ne parlais que de rendu.

Comme je l'écrivais, les noms des relations sont affichés en petit le 
long des frontières mais ne sont plus visibles nulle part à zoom 14 et 
moins.


Comme les communes nouvelles n'ont théoriquement pas de nœud place=*, 
rien n'est rendu sur la carte OSM au-dessous de zoom 14.


Pour les communes nouvelles, comme elles conservent la toponymie des 
communes membres, le nom de la commune nouvelle ne remplace pas celui 
des communes membres, qui conservent également leur code INSEE propre 
à 5 chiffres (même si ces communes ne sont plus de "plein exercice" en 
tant que personnes morales séparées, le code INSEE à 5 chiffres est un 
code géographique, pas un code sur la personne morale qui, elle, est 
codée avec le code SIREN). La commune nouvelle adopte simplement le 
code INSEE à 5 chiffres d'une de ses communes membres, celle de son 
chef-lieu, les "anciens" codes INSEE à 5 chiffres ne sont pas 
"supprimés", il restent en vigueur et même liés aux communes membres. 
L'association du code INSEE à 5 chiffres avc la commune nouvelle est 
seulement une "facilité".


Tu parles de contraintes administratives, moi je parlais de terrain et 
d'utilisateurs (habitants, livreurs, voyageurs) qui ont besoin de 
connaître où se trouve la commune qui est mentionné sur leur bon de 
livraison ou qui est la destination de leur voyage. De plus en plus le 
nom de la commune nouvelle apparaît seule sur les adresses. Les noms des 
communes anciennes tendent à disparaître des adresses postales et des 
bons de livraison (les doublons sont pourchassés et progressivement 
éliminés par une numérotation différenciés des maisons, exemple : de 1 à 
30 sur telle rue et de 40 à 60 sur une homonyme).


Si on laisse en l'état, la seule solution est de faire un autre rendu, 
ce qui est hors de portée du pékin moyen. La recherche Nominatim 
fonctionne bien mais ne change rien au rendu utile pour se situer dans 
les derniers km.


La distinction entre entités administratives de niveau différent est 
pertinente pour l'administration (et pour les cartographes et autres 
spécialistes) mais beaucoup moins pour le citoyen moyen. De plus 
certaines mairies seraient bien intéressées par une meilleure visibilité 
de leur commune pour leurs propres services, pour la cohésion de leurs 
habitants et pour la promotion de leur commune à l'extérieur.


En résumé, le problème est l'utilisabilité et la visibilité de la carte 
OSM pour le terrain. Ce n'est ni un problème administratif, ni un 
problème de structure de la BDD d'OSM, quoique des changements mineurs 
pourraient aider.


Va falloir forker la carte OSM ;).

--
Rpnpif


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

Re: [OSM-talk-fr] Rendu OSM et fusion de communes

[Rpnpif via Talk-fr]

Le 28/05/2020 à 17:16, Jean-Claude Repetto a écrit :

Je parlais bien de place=locality:
https://wiki.openstreetmap.org/wiki/FR:Tag:place%3Dlocality
qui est traduit par lieu-dit dans OSM. 


Euh, je lis « lieu-dit sans population » :


/Locality/ désigne un lieu-dit (au sens littéral du terme) sans 
population. Les lieux-dits (dans le langage courant) ou hameaux 
peuplés doivent être tagués avec place 
=hamlet 
.



Ce qui est exact.

--

Rpnpif

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

Re: [OSM-talk-fr] Rendu OSM et fusion de communes

[Rpnpif via Talk-fr]

Le 28/05/2020 à 15:29, Jean-Claude Repetto a écrit :

Bonjour,

Je réponds partiellement:

Le 28/05/2020 à 14:45, Yann-Gaël LARGILLET a écrit :


Je me permets d'écrire sur cette liste, merci de me dire si ce n'est 
pas le bon endroit. J'ai envoyé un message sur le forum, mais j'ai 
l'impression que ma question aura peut-être plus de chances de 
réponses sur cette liste !


Oui, cette liste est beaucoup plus active que le forum.

"Saint-M'Hervon" a été engloutie par la commune de 
"Montauban-de-Bretagne". J'ai donc transformé le point en lieu-dit, 
est-ce ok ?


Non, un lieu-dit n'a pas d'habitants. Je pense que "village" est plus 
approprié.


Bonjour,

Un lieu-dit, mot générique, peut avoir des habitants ou pas car place 
signifie lieu-dit (un village est aussi un lieu-dit). Sans habitant, 
c'est place=locality.


Et bien se souvenir que il n'y a malheureusement aucun rendu pour le 
moment des communes nouvelles issues de la fusion sur la carte 
officielle https://www.openstreetmap.org/ sauf, comme dans ce cas, si la 
commune ne change pas de nom. Dans ce cas et autrement, on ne voit que 
les communes anciennes sur la carte, marquées par un point place=village 
ou bien place=* (autre). Alors que pour toutes les communes anciennes 
fusionnées ou pas, un point place=* est placé traditionnellement en plus 
de la frontière sous forme de relation même si la commune ancienne 
comprend plusieurs place=village (agglomérations de plus de 200 
habitants). La raison est que les relations comportant le nom de la 
commune nouvelle ne sont pas malheureusement non plus rendues (sauf le 
long de la frontière de la commune en tout petit).


La carte https://www.openstreetmap.org/ a choisi de ne pas représenter 
les surfaces place=* pour une raison qui m'est inconnue contrairement à 
l'application OsmAnd.


Comme la communauté française a choisi de ne pas ajouter de point 
place=* pour les communes nouvelles (alors que pour les habitants de 
plus en plus celles-ci sont entrées dans la vie quotidienne entre autres 
pour des raisons postales et de transports) et bien ces communes sont 
invisibles sur ce rendu comme sur celui de openstreetmap.fr.


Dommage.

--
Rpnpif


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

Re: [OSM-talk-fr] Structures de soins en addictologie (CSAPA, CAARUD…)

[Rpnpif via Talk-fr]

Réponse rapide.

Le 12/02/2020 à 11:01, Yves P. a écrit :

Bonjour,

[...]
*Faut-il nettoyer les données OSM ?*
Une recherche (NOMINATIM) avec le terme CSAPA 
 renvoi 
« Clinique », « Hospital », « Service social » , « Salle polyvalente ».


Une recherche Overpass avec "social_facility:for"=drug_addicted en 
France  montre que les tags 
amenity=social_facility et social_facility=* ne sont pas toujours 
présents.
Je dirais plutôt proposer une règle Osmose au lieu d'une modification 
massive.


--
Rpnpif


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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Rpnpif via Talk-fr]

Merci d'avoir pris en compte ce problème et merci pour vos suggestions 
(place=municipality) qui me font réfléchir..


Le problème est assez peu différent pour les communes anciennes et non 
fusionnées récemment ayant plusieurs agglomérations séparées. 
L'admin-centre n'est pas forcément l'agglomération la plus grande mais 
celle où est se situe le bâtiment de la mairie et on y met un place=* 
(Oui, Florimond, j'ai bien compris tes griefs et exemples).


J'aurais une suggestion qui va peut-être choquer : ce serait de 
remplacer place=village/town des anciennes communes incluses dans la 
fusion par des place=quarter/neighborough et de placer le nom de la 
nouvelle commune sur l'admin-centre en place=village/town/city comme on 
le fait pour Nantes, Paris, etc. toutes issues de fusions plus ou moins 
anciennes (oui bon la différence, c'est que ces communes ont gardé le 
nom de la commune principale).


Parce que, à priori, les communes dites déléguées ne sont que de futurs 
arrondissements ou quartiers de la nouvelle. Aujourd'hui, ce sont des 
sortes de quartiers à statut spécial.


--
Rpnpif

Le 11/02/2020 à 18:03, Christian Quest a écrit :

Prenons un exemple pour réfléchir:

- Montholon (commune nouvelle): place=municipality + population=1500

  - Aillant-sur-Tholon (commune chef-lieu): place=village + 
population=1000


  - Volgré (commune déléguée): place=village + population=300

  - Villiers-sur-Tholon (commune déléguée): place=village + 
population=200


Chaque noeud est admin_centre d'une relation admin_level=8 ou 9


Sur le rendu, Montholon sera placé en priorité, puis Aillant, puis 
Volgré, puis Villiers.


Comme on aura plus le détail des populations des communes déléguées 
(quoique*) on peut conserver ce qu'on a de plus récent et on a le 
millésime en source:population


De toute façon, quelqu'un qui aurait besoin des populations à jour 
ferait quand même bien mieux (en France) de prendre le fichier de 
l'INSEE ;)



Place sur la relation + sur le noeud ? Bof bof bof, ça ne me semble 
pas cohérent car on a un doublon de place=* (qui décrit un objet, 
contrairement à population=* qui n'est pas un "objet" en tant que tel 
mais un attribut d'un objet).



* avec le carroyage INSEE on pourrait très bien déduire 
approximativement la population d'un hameau, d'un écart, etc...





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

Re: [OSM-talk-fr] Tag panneau zone vidéo surveillance ?

[Rpnpif via Talk-fr]

Le 11/02/2020 à 10:37, Jérôme Seigneuret a écrit :




à chaud, j'aurais créé traffic_sign=surveillance
___

Pour moi c'est pas en lien avec le traffic

A chaud ;-)
tourism=information
information=bord
bord_type=surveillance


Tu veux dire :

Information=board
board_type=surveillance

;)

--
Rpnpif

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

[OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Rpnpif via Talk-fr]

Je voudrais proposer de modifier la façon de traiter les communes 
nouvelles françaises dans OSM.


Je considère qu'une nouvelle commune devrait être enregistrée de la même 
façon qu'une ancienne commune issue de fusion de plusieurs communes.


La possibilité de fusion des communes en France est très ancienne, elle 
a plus de 50 ans. Par exemple, certaines communes sont issues d'une 
campagne de fusion des années 1970. Ces dernières portent souvent le nom 
des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont 
pas distinguées des communes non issues de fusion (ou plutôt, celles 
dont on se souvient qu'elles ne sont pas issues de fusion ; si on 
remonte très loin, au Moyen-Âge, ces communes non issues de fusion 
doivent être assez rares).


De façon que je considère arbitraire, les communes issues de fusion 
d'après 2010 (pourquoi ne pas prendre celles avant 2010 ?) , il a été 
décidé ici même de traiter à part les communes nouvelles en ne les 
enregistrant que par leur frontière et sous forme de relation avec leurs 
anciennes communes membres et leur admin_centre. Il a aussi été décidé 
de ne pas les repérer par un nœud place=* contrairement aux communes 
d'avant 2010 même issues de fusion (donc beaucoup comme on l'a vu).


La conséquence la plus visible est que ces communes sont totalement 
invisibles dans le rendu officiel osm.org qui n'affiche pas le nom des 
zones englobées par une frontière sans place=*.  Il y a pourtant 
d'autres limites dont le nom est affiché comme les forêts, etc. 
Geoportail de l'IGN affiche bien, lui, ces nouvelles communes.


On répond que les nouvelles communes ne sont que des délimitations 
administratives qui n'ont pas vocation à être des lieux-dits. Cette 
opinion est contestable car c'est pourtant comme cela que l'on note les 
anciennes communes issues ou non de fusion. De plus dans l'esprit du 
législateur, les nouvelles communes issues de fusions récentes ont 
vocation à fonctionner comme les autres communes en intégrant 
complètement les anciennes qui ne deviennent que des sortes de quartiers 
ou arrondissements. Ces anciennes communes peuvent être des villages et 
parfois des petites villes (plus de 1 habitants aux abords d'une 
grande agglomération).


Par exemple, une commune classique non issue de fusion récente comporte 
souvent un bourg qui est appelé Le Bourg par les habitants et est 
rarement repéré par ce nom dans Osm.org (alors que BANO peut le 
marquer). En général, la mairie décide de noter sur les panneaux 
d'entrées du bourg le nom de la commune. Donc la commune est aussi un 
lieu-dit qui devrait être noté par place=* au niveau du bourg ou de 
l'agglomération principale. Dans le cas d'une commune issue de fusion 
récente, certaines mairies n'affichent que le nom de la commune issue de 
fusion et pas l'ancienne. D'autres affichent le nom de l'ancienne 
commune avec mention du nom de la nouvelle dessous. Évidemment, quand le 
nom de la commune issue de la fusion est le même que celle de celui de 
la commune admin_centre, le problème est plus simple.


Les habitants et autres partenaires des nouvelles communes récentes font 
de moins en moins la distinction avec le fonctionnement des communes non 
fusionnées récemment que ce soit pour leurs relations avec la mairie, la 
Poste, etc. (bien sûr après un temps d'adaptation plus ou moins facile 
et plus ou moins heureux). Ils ont donc de plus en plus besoin de 
repérer leur commune nouvelle sur une carte.


En conséquence de ce que j'écris ci-dessus, ma proposition est la suivante :

Traiter les nouvelles communes comme les anciennes avec une relation 
frontière (boundary) et un nœud place=* mis aux abords de l'admin-centre 
ou bien vers le centre de la commune.


Garder le nœud place=* et la relation frontière (boundary) des anciennes 
communes comme on le fait déjà pour les place=village des lieux-dits 
d'agglomération de plus de 200 et de moins de 1 habitants à 
l'intérieur d'une commune « non fusionnée » récemment.


Cette proposition permet de simplifier les contributions ainsi que les 
moteurs de rendus.


--
Rpnpif


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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Rpnpif via Talk-fr]

Le 10/02/2020 à 18:00, leni a écrit :


Le 10/02/2020 à 12:29, Stéphane Péneau a écrit :

Si je récapitule :

- Vincent lance l'outil aidant la maj de la population sur les 
relations des communes.


- Je soulève l'idée de supprimer le tag "population" des noeuds car 
ce n'est pas cohérent.


- Christian indique qu'il l'utilise

- Discussions sur les différents cas qui se présentent. Avec 
plusieurs propositions de supprimer "population" des noeuds.


- J'indique que si c'est utilisé par le rendu FR, ça bloque un peu ce 
processus.



Dans ma tête, j'en suis resté à l'idée qu'il fallait le conserver 
pour l'instant, et sur les maj que j'ai effectuées, j'ai copié la 
valeur de "population" sur le noeud "admin_centre".


j'ai fait pareil après avoir lu le message de Christian 


Bonjour,

Dupliquer la population sur l'admin-centre me semble une mauvaise idée 
surtout sur les nouvelles communes. En effet, elle a pu être mise à jour 
pour cette ancienne commune seulement et n'a donc pas la même valeur que 
la nouvelle. Je rappelle que beaucoup (la majorité ?) de nouvelles 
communes n'ont pas le même nom que l'ancienne et aussi que l'ancienne 
peut avoir deux relations admin_centre (pour elle-même et pour la nouvelle).


D'ailleurs, le traitement des nouvelles communes et particulièrement 
leur rendu est un problème à part entière qui est très mal traité par le 
rendu osm.org, contrairement à Géoportail (de l'IGN) qui fait bien 
apparaître son nom.


Je vais lancer un autre fil de discussion sur ce problème des nouvelles 
communes.


Rpnpif


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

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Alain Rpnpif via Talk-fr]

Le 05/02/2020 à 07:20, Vincent de Château-Thierry a écrit :

Bonjour,



Bonjour Vincent,

Il semble que quelqu'un conteste tes mises à jour ou plutôt ne les as 
pas comprises. C'est sur :


https://forum.openstreetmap.org/viewtopic.php?id=68546

Rpnpif


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

Re: [OSM-talk-fr] Eglise désacralisée et cimetière

[Rpnpif via Talk-fr]

Le 25 novembre 2019, Donat ROBAUX a écrit :

> Je suis également pour laisser les tag religion et denomination. Pq?
> Parce qu'un temple protestant et une église catholique n'ont pas la même
> architecture. Et même si on démonte les croix, il reste parfois des vitraux
> ou des sculptures.
> On peut également trouver des anciennes synagogues qui ne servent plus au
> culte. Donc laisser les tags me parait important pour "conserver"
> l'historique. De même que je passe le name en old_name.

Je ne trouve pas que ce soit pertinent car au fur et à mesure du
temps, ces objets parfois discrets disparaissent et on ne peut
distinguer la "denomination" catholique de l'orthodoxe ou autre, etc.
Il n'y a pas d'architecture nommée catholique ou même chrétienne.
Je connais d'anciennes églises qui sont transformées en magasin (de
vêtements par exemple). Pas un magasin catholique ! J'en connais même
une transformée en étable (la crèche ? :)) ).
Sinon si on suit le raisonnement de Donat, une croix présente dans une
maison d'habitation permettrait de marquer le bâtiment par religion=*,
ce qui serait abusif.

C'est la même chose pour les cimetières municipaux soit la
grande majorité des cimetières en France (hors Alsace ?). Ils sont
légalement laïques et pourtant on y trouve beaucoup de croix
chrétiennes. Mais aussi des tombes sans objets religieux et d'autres
avec le croissant musulman ou des signes juifs.
Et pourtant beaucoup de cimetières sont marqués de façon erronée
religion=christian. Il serait plus pertinent de marquer une simple
tombe avec une croix chrétienne par religion=christian. J'enlève
systématiquement cet attribut sur les cimetières (je les laisse sur les
tombes).
L'exception sont les cimetières assez rares de communautés religieuses
qui dérogent.

Cela n'empêche pas d'avoir parfois à l'intérieur des cimetières
municipaux des calvaires catholiques ou au moins chrétiens qui eux
peuvent être marqués place of worship et religion=* s'ils sont encore
utilisés pour le culte.

Et les anciennes écoles catholiques, va t-on taguer les bâtiments
religion=* ? non bien sûr. Et bien c'est le même raisonnement pour les
anciennes églises.

Par contre, d'accord avec les propositions avec une date de fin ou
disused:, etc.

En résumé, à mon avis, ne disséminons pas le tag religion=* à tout vent,
seulement à bon escient, sinon tout devient religieux à tort.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] [SPAM] Re: absence de licence sur "adresse-francaise.com": copyvio? vie privée/CNIL?

[Rpnpif via Talk-fr]

Le 27 novembre 2019, Philippe Verdy a écrit :

> En attendant on est toujours bombardé tous les jours de spammeurs et
> démarcheurs par courriel, téléphone fixe, mobile, maintenant aussi par
> courrier concernant les prétendues offres "d'isolation à 1 euro" pour tous
> (et ceci malgré la condamnation récente par la CNIL d'une de ces sociétés,
> cela continue, aujourd'hui par courier postal d'une "société" à
> Nogent-sur-Marne (avant à Melun), sous pli téléimprimé, et qui se dit
> "agence française de l'habitat" (autre nom à Neuilly-sur-Seine, mais qui
> déménage souvent, peut-être maintenant à Levallois, Gennevilliers,
> Courbevoie) avec de nouvelles variantes mineurs dans le nom ("officielle",
> "nationale", "pour l'amélioration de l'habitat", "institut", etc...)
> aujourd'hui cette société continue et utilise les mêmes données abusives.

+1 et ras-le-bol !

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] switch2OSM

[Rpnpif via Talk-fr]

Le 28 septembre 2019, osm.sanspourr...@spamgourmet.com a écrit :

> Joli poisson : sur la carte des Pages Jaunes (Mappy) j'ai eu la surprise
> de voir :
> 
> © Mappy 
> | 2018 TomTom, OpenStreetMap.
> 
> Bien ? Oui et non car seul Mappy est muni d'un lien.
> 
> Et le lien
> https://blog.mappy.com/entreprise/conditions-dutilisations/copyright/
> 
> © Mappy 2018. Tous droits réservés, reproduction interdite.
> 
> Par vraiment ODbL mais s'ils parlent des tuiles pourquoi pas.
> 
> Et les différentes sources de données se voient attribuées les
> copyrights qui vont bien.
> 
> Toutes ? Non visiblement on peut se moquer des données communautaires et
> des collectivités :
> 
> 2. AUTRES DONNÉES GÉOGRAPHIQUES
> Natural Earth
> GeoNames
> OpenStreetMap
> IleDeFranceMobilité
> Toulouse
> Lorient
> Lille
> 
> Oui, aucun lien vers les copyrights et conditions d'utilisation respectifs.
> 
> Christian, tu dis que les entreprises sont assez réactives si on les
> titille sur Twitter, tu peux vérifier : https://twitter.com/Mappy

Bonjour,
Je ne leur en veux pas car ils utilisent tellement mal les données
OpenStreetmap qu'ils n'y intègrent pas des erreurs de noms de lieux
corrigées depuis plus de 5 ans dans OSM.

-- 
Alain Rpnpif

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

[OSM-talk-fr] Action sur vandalisme demandée

[Rpnpif via Talk-fr]

Bonjour,

Une question sur le forum ici :
https://forum.openstreetmap.org/viewtopic.php?id=67452

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] école primaire

[Rpnpif via Talk-fr]

Le 19 septembre 2019, Dominique Rousseau a écrit :

> Le Thu, Sep 19, 2019 at 10:27:58AM +0200, Christian Quest 
> [cqu...@openstreetmap.fr] a écrit:
> [...]
> > >
> > > En toute logique, maternelle, élémentaire et primaire sont trois options
> > > d'amenity=school.  
> > 
> > +1
> > 
> > Chaque pays définissant un age à partir duquel on passe de la garderie
> > (optionnelle) à l'école (obligatoire), ce n'est pas à l'age que le tag
> > devrait faire référence.
> > 
> > En gros, je pense qu'à partir du moment ou c'est de l'école obligatoire on
> > devrait passer en amenity=school  
> 
> En France, l'école n'est pas obligatoire, c'est l'instruction qui l'est.
> Et depuis que l'âge est passé à 3 ans, l'accueil en "jardin d'enfants"
> (aka kindergarten ;-)) peut faire "office de" [1] :
> 
> https://www.service-public.fr/particuliers/vosdroits/F21370
> 
> 
> Et pour ce qui concerne les tags OSM et le wiki, je pense qu'on devrait
> effectuer une modification pour établir que, pour la France, quand c'est
> une « école », c'est amenity=school ; amenity=kindergarten étant utilisé
> pour les établissements d'accueil pré-scolaire.
> ( pour les autres pays francophones, je ne connais pas du tout leur
> fonctionnement )
> 
> 
> 
> [1] pour le coup, c'est un autre débat que de dire si un acceuil en
> crèche/garderie peut assurer l'instruction de la même facçon que le
> programme d'école maternelle, et poltiquement, ça ressemble à une
> tendance vers la kindergartenisation de l'école maternelle.
> 

Tout est dit par Dominique.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] hebdoOSM Nº 474 2019-08-13-2019-08-19

[Rpnpif via Talk-fr]

Le 29 août 2019, theweekly@gmail.com a écrit :

> Bonjour,
> 
> Le résumé hebdomadaire n° 474 de l'actualité OpenStreetMap vient de paraître 
> *en français*. Un condensé à retrouver sur :
> 
> http://www.weeklyosm.eu/fr/archives/12335/
> 
> Bonne lecture !
> 
> Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
> hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
> https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir 
> plus sur la rédaction d'un article, cliquez ici: 
> http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

Bonjour,

...
> Le nouveau projet du trimestre britannique consiste à cartographier les 
> panneaux solaires sur les toits. Cela aidera à prévoir le comportement de la 
> grille électrique

grille-pain ?
Les pièges de la traduction automatique ;).

electrical grid = réseau électrique.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Track -> Chemin rural

[Rpnpif via Talk-fr]

Le  8 août 2019, marc marc a écrit :

> track à mes yeux est hors "réseau routier", c'est un chemin agricole, 
> forestrier, agriculture, loisir (parc). c'est typiquement le chemin que
> vous ne prenez jamais en voiture malgré que la largeur le permet

Que vous ne prenez presque jamais parce qu'il n'y a que rarement
interdiction formelle (en France) si l'état du chemin le permet.
Sinon d'accord.

-- 
Alain Rpnpif

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