Re: [OSM-talk-fr] site utilisant survey:date et la date metadata

[althio]

Geocropping ?
https://geocropping.xsalto.com/
https://play.google.com/store/apps/details?id=geocropping.com.geocroppingapp


On Sun, Apr 12, 2020, 00:32 Marc M.  wrote:

> Bonjour,
>
> Quel site montrait les objets en fonction de
> survey:date et/ou date de dernier modif ?
>
> Cordialement,
> Marc
>
> ___
> 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] Rue trop étroite pour que 2 voitures se croisent ?

[althio]

lanes=1
width=*

voir aussi
narrow=yes
https://wiki.openstreetmap.org/wiki/Key:narrow

On Sat, 11 Apr 2020 at 15:06, Lionel Allorge via Talk-fr <
talk-fr@openstreetmap.org> wrote:

> Bonjour,
>
> Le passage Perron à Saint-Rémy-lès-Chevreuse
>  est une ruelle étroite qui
> est autorisée à la circulation des véhicules dans les deux sens mais il
> est en pratique impossible de s'y croiser. Il faut donc attendre que la
> voiture engagée en sorte pour y passer.
>
> J'ai cherché dans le wiki mais je n'ai rien trouvé pour signaler ce cas
> de figure.
>
> Merci d'avance pour vos propositions.
>
> Bon confinement.
>
> --
> Lionel Allorge
> 
> « Ne craignez jamais de vous faire des ennemis; si vous n'en avez pas,
> c'est que vous n'avez rien fait »
> Clemenceau
>
> ___
> 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] #caresteouvert Intégration données dokomaps en opendata

[althio]

En l'absence de clarification complète ou d'autres éléments convaincants
sur le statut des données Doko Maps, leur propriété et leur licence, je
considère que ces données ne sont pas valables pour un ajout dans OSM.

La discussion avec les différents auteurs de cet ajout de données et le
reste de la communauté n'a pas eu lieu (en tout, pas aussi détaillée et
conclusive qu'on aurait pu espérer), ni ici sur talk-fr, ni sur
https://github.com/osmontrouge/caresteouvert/issues/81

J'ai fait une demande aux auteurs de cet ajout de données de reverter leurs
contributions, ce qui a été ignoré pour l'instant.
cf.
https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-611299417

Je lance donc un dernier appel sur cette liste, si quelqu'un :
- veut exprimer son opinion en faveur ou défaveur de la validité de ces
données dans OSM, et pour ou contre des reverts
- voire un appel à volontaires pour effectuer les reverts si les auteurs
initiaux ne s'en chargent pas

On Sat, 4 Apr 2020 at 21:52, althio  wrote:

> Bonjour,
>
> Merci pour le suivi, les renseignements complémentaires et la mise à jour
> des informations.
>
> > Alors, en regardant plus en détails, sur les deux catégories de données :
>> >
>> > - données des contributeurs (commentaire) : je n'ai pas trouvé non plus
>> de
>> >   Terms of Services ou équivalent, donc c'est effectivement une zone
>> >   grise.  Je vais demander.
>>
>> Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut considérer
>> qu'ils nous ont accordé une licence et que la base juridique de cet accord
>> vis-à-vis de leurs utilisateurs les regarde, mais c'est sûr que c'est
>> problématique.  Dans ce cas particulier, vu la situation et le caractère
>> d'utilité publique de ces données, je ne pense pas qu'il faille bloquer /
>> reverter le travail d'import pour autant.
>>
>
> Tu ne le penses pas, certes, mais il faudrait demander à la communauté,
> voire demander des conseils de manière plus large (liste
> impo...@openstreetmap.org, Data WG, Legal WG...).
>
> "Du point de vue d'OSM, on peut considérer qu'ils nous ont accordé une
> licence et que la base juridique de cet accord vis-à-vis de leurs
> utilisateurs les regarde"
> C'est un peu cavalier, ça ressemble à du recel : la donnée n'a pas de
> licence valable, on le sait, mais on la garde quand même.
> D'autre part, si on veut intégrer dans OSM, la licence et la base
> juridique nous regarde aussi, beaucoup.
> OpenStreetMap est un projet collaboratif international avec des valeurs,
> un partage des données, un partage des méthodes, et un certain partage des
> risques.
> Ce n'est pas une start-up qui bidouille dans son coin pour son propre
> compte.
>
> Pour ma part, je pense que cette source de données est un bien faible
> gain, au regard des conditions problématiques.
> Pour ce qui est de bloquer ou d'annuler les contributions déjà
> effectuée... c'est sûr que c'est maintenant compliqué, il aurait été plus
> facile de prendre son temps et de tirer les choses au clair avant
> d'intégrer les données.
>
> "vu la situation et le caractère d'utilité publique de ces données" n'est
> pas un argument recevable pour justifier d'un ajout de données
> problématique.
>
> La conflation des données s'appuie toujours - je suppose - sur les données
> initiales (nom, localisation, ...).
> Il y a une tolérance du côté d'OSM pour permettre cela à d'autres
> utilisateurs vers d'autres bases.
> Je ne pense pas que cela soit autorisé aussi clairement par Google pour
> ses services et données.
>
> Franchement, avec ou sans conflation, la problématique est peut-être la
> même. Ces données sont teintées Google Maps, nous ne devrions pas y toucher
> - à mon avis - pour compléter OSM.
>
> Et vous devriez arrêter cette contribution, avec ou sans conflation, pour
> étudier proprement la question, arriver à un consensus sur la démarche à
> suivre, et l'appliquer.
>
> - althio
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Phramacies][Licence] Intégration Osmose des professionnels de santé (infirmières, kinésithérapeutes…)

[althio]

La licence, sur http://sante.fr et http://annuairesante.ameli.fr
ça joue pas (ce qui est assez désespérant, je trouve).

Mais, comme indiqué dans le premier message par Yves, le jeu de données qui
semble intéressant est disponible sur data.gouv.fr avec une licence ouverte.

"Il existe en données ouvertes : Infos pratiques professionnels de sante
 avec sa
description

"

Ou alors j'ai loupé un épisode ?


Je relance sur la licence de :
>
> https://sante.fr/conditions-generales-dutilisation
>
> Ca joue ou ça joue pas ?
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] restrictions temporaires

[althio]

Un bon exemple sur la page :
motor_vehicle:conditional=no @ (2018 May 22-2018 Oct 7)

Donc quelque chose approchant :
access:conditional=no @ (2020 Mar ??-2020 Apr ??)

On Wed, 8 Apr 2020 at 16:28, DH  wrote:

> Bonjour,
>
> De plus en plus de restrictions d'accès temporaires (sans date de fin
> connue) sont posées sur divers catégories d'objets : tunnels, pistes
> cyclables, ...
>
> Comment taguer (pour l'exemple : le tunnel de Schirmeck à fort impact
> pour les calculateur d'itinéraires ) ?
>
> J'étais parti sur un "date_off" mais visiblement déprécié (warning JOSM
> -> OK)
>
> Selon https://wiki.openstreetmap.org/wiki/Conditional_restrictions,
> j'arrive sur => access:conditional=no @ (<2020-04-19>)
>
> J'ai tout bon ?
>
> Denis
>
>
> ___
> 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] La Poste - fichier covid19 des bureaux

[althio]

On Wed, 8 Apr 2020 at 13:58, Frantz  wrote:

> Bonjour,
>
> La Poste vient de mettre à disposition la liste des bureaux
> ouverts/fermés/horaires par semaine en pdf et xls.
>
> https://www.laposte.fr/particulier/outils/trouver-un-bureau-de-poste
>
> Utilisable ?
>

A comparer si il s'agit des mêmes données :
https://datanova.laposte.fr/explore/dataset/laposte_ouvertur/information/?sort=identifiant
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Compatibilité OdbL avec OdbL [était / Re: #caresteouvert Intégration données dokomaps en opendata]

[althio]

Vincent  :

> 1. Attention, ce n'est pas intuitif, mais la compatibilité d'une licence
> ODbL est un peu grise pour l'ajout dans OSM.
> cf. https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility
> cf. https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
>
> je ne suis pas sur de comprendre le gris :(
>
Alors je passe en anglais et en mode "archiviste", désolé ^^
C'est temporaire, la suite sera en français.

Do you understand "grey"? ;) ;) ;)
If you understand English, you can read some bits here and there:

https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#I_would_like_to_import_data_XYZ.2C_can_I_just_go_ahead.3F
https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#Can_third-party_ODbL-licensed_data_be_imported.3F

and some previous discussions:
https://lists.openstreetmap.org/pipermail/imports/2017-July/005112.html
https://lists.openstreetmap.org/pipermail/imports/2017-October/005217.html
;
https://lists.openstreetmap.org/pipermail/imports/2017-November/005218.html
;
https://lists.openstreetmap.org/pipermail/imports/2017-December/005262.html


--- éléments en français ---
La licence des données OSM peut légalement / théoriquement /
potentiellement être changée.
C'est écrit dans l'accord entre chaque contributeur et la fondation :

https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms/FR
2. Droits concédés. Vous concédez à OSMF, dans les conditions définies aux
articles 3 et 4, de manière irrévocable et perpétuelle, une licence [...]
3. OSMF consent à n’utiliser ou sous-licencier votre Contenu [...]
seulement par [...] ODbL [...] ; ou toute autre licence libre et ouverte
[...] choisie par une majorité de 2/3 des contributeurs actifs parmi les
membres d’OSMF.
4. OSMF accepte de Vous citer ou de citer le titulaire des droits d’auteur
[...].

Si la donnée vient directement d'un contributeur, un éventuel changement de
licence serait transparent, puisque que c'est consenti dans les termes
cités (article 2 en relation avec articles 3&4), même pour un changement
futur de licence (libre et ouverte).
Si la donnée vient d'un tiers, qui n'a pas directement approuvé ces termes,
le changement de licence d'OSM peut se trouver en contradiction avec la
licence d'origine des données. Puisque le titulaire des droits n'a pas
donné son accord par les termes du contributeur ou par une autre façon, les
données ne peuvent être conservées dans OpenStreetMap.

Ce n'est pas que théorique : OSM a déjà changé de licence, ce qui a
entraîné des effacements de données (si ma mémoire est bonne, parce que les
termes du contributeur de l'époque ne permettait pas le changement de
licence et il fallait obtenir l'accord a posteriori de chaque contributeur
passé).


Et en partant du principe que c'est gris cependant, cela veut dire qu'il
> est préférable de :
>
>- évidemment dans tous les cas s'assurer que la structure qui fournit
>le jeu de données a les droits pour cela et donc être sur de qui a
>constitué ce jeu de données, l'accord explicite de contribution s'étendant
>à chaque personne ayant participé ?
>
> Évidemment.

Juste, pour le cas qui nous occupe ici et pour faire un parallèle, un autre
éclairage...
Imaginons, prenons une situation hypothétique :
* OSM-FR héberge un service de carte collaborative sous le nom de uMap.
* OSM-FR propose l'utilisation de cet outil pour renseigner des données
(soit des cartes privées, soit des cartes publiques).
* Durant la crise du Covid-19, les personnes sont invitées à contribuer sur
une carte uMap, pour partager des informations locales.
* Puis OSM-FR décide de prendre le contenu de ces cartes, de se déclarer
propriétaire des données, d'y apposer une licence et de les utiliser à
d'autres fins.

On peut dire, je crois, que OSM-FR et la communauté OSM ne se permettrait
ce genre d'actions.

Maintenant, remplacer "OSM-FR" par "Société-X" et remplacer "uMap" par
"X-Maps".
Il est donc, de mon point de vue, étrange d'accepter ce comportement et ces
données, quand elles viennent d'un tiers.



>
> en partant du principe que c'est gris cependant, cela veut dire qu'il est
> préférable de [...]
>
>- demander la licence LO ou demander la licence OdbL avec accord
>explicite des conditions de contributions à OpenStreetMap
>https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms/FR
>
>
Je pense que oui.
De façon très générique, par ordre de préférence :

- 1er choix "mode Ouvre-Boîte universel" :
avoir la licence LO (ou équivalent), pour une libération générale, à tous
les usages pour tout le monde, dont OpenStreetMap.

- 2e choix "mode ouverture propre" :
avoir la licence ODbL avec accord explicite des conditions de contribution
à OpenStreetMap.
[
https://wiki.openstreetmap.org/wiki/FR:Import/Getting_permission#Letter_Template3
]

- 3e choix "mode mains sales un peu grises" (attention, se laver les mains
est une des meilleures protections contre la propagation des maladies).
faire avec une license ODbL.
C'est acceptable 

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

[althio]

Bonjour,

Merci pour le suivi, les renseignements complémentaires et la mise à jour
des informations.

> Alors, en regardant plus en détails, sur les deux catégories de données :
> >
> > - données des contributeurs (commentaire) : je n'ai pas trouvé non plus
> de
> >   Terms of Services ou équivalent, donc c'est effectivement une zone
> >   grise.  Je vais demander.
>
> Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut considérer
> qu'ils nous ont accordé une licence et que la base juridique de cet accord
> vis-à-vis de leurs utilisateurs les regarde, mais c'est sûr que c'est
> problématique.  Dans ce cas particulier, vu la situation et le caractère
> d'utilité publique de ces données, je ne pense pas qu'il faille bloquer /
> reverter le travail d'import pour autant.
>

Tu ne le penses pas, certes, mais il faudrait demander à la communauté,
voire demander des conseils de manière plus large (liste
impo...@openstreetmap.org, Data WG, Legal WG...).

"Du point de vue d'OSM, on peut considérer qu'ils nous ont accordé une
licence et que la base juridique de cet accord vis-à-vis de leurs
utilisateurs les regarde"
C'est un peu cavalier, ça ressemble à du recel : la donnée n'a pas de
licence valable, on le sait, mais on la garde quand même.
D'autre part, si on veut intégrer dans OSM, la licence et la base juridique
nous regarde aussi, beaucoup.
OpenStreetMap est un projet collaboratif international avec des valeurs, un
partage des données, un partage des méthodes, et un certain partage des
risques.
Ce n'est pas une start-up qui bidouille dans son coin pour son propre
compte.

Pour ma part, je pense que cette source de données est un bien faible gain,
au regard des conditions problématiques.
Pour ce qui est de bloquer ou d'annuler les contributions déjà effectuée...
c'est sûr que c'est maintenant compliqué, il aurait été plus facile de
prendre son temps et de tirer les choses au clair avant d'intégrer les
données.

"vu la situation et le caractère d'utilité publique de ces données" n'est
pas un argument recevable pour justifier d'un ajout de données
problématique.

La conflation des données s'appuie toujours - je suppose - sur les données
initiales (nom, localisation, ...).
Il y a une tolérance du côté d'OSM pour permettre cela à d'autres
utilisateurs vers d'autres bases.
Je ne pense pas que cela soit autorisé aussi clairement par Google pour ses
services et données.

Franchement, avec ou sans conflation, la problématique est peut-être la
même. Ces données sont teintées Google Maps, nous ne devrions pas y toucher
- à mon avis - pour compléter OSM.

Et vous devriez arrêter cette contribution, avec ou sans conflation, pour
étudier proprement la question, arriver à un consensus sur la démarche à
suivre, et l'appliquer.

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

[althio]

t été vérifiées.
Je pense ça correspond avec ton idée initiale ("je détaillerai une idée de
processus quand on sera d'accord sur le principe").

Vous avez déjà fait une grande partie de ce qui est requis, de ce que j'ai
vu passé.
Et la documentation est en cours aussi, avec
https://wiki.openstreetmap.org/wiki/France/Covid-19/Imports

Il faut donc prendre les règles d'import comme un pense-bête, une liste
pour bien passer en revue les points importants.

Et surtout clarifier les aspects de propriété de la donnée et de licences,
avant présenter les données.
Et attendre les accords sur le principe et les accords sur les détails
avant de se lancer.

Bon courage

- althio

[1] https://wiki.openstreetmap.org/wiki/FR:Import/Guidelines
> ___
> 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] Carte des limites de vitesseq

[althio]

C'est maintenant plus clair et officiel, avec une page de redirection et
une annonce :
https://www.itoworld.com/ito-map-announcement/

On Mon, 29 Jul 2019 at 13:09, Eric SIBERT  wrote:

> Le 29/07/2019 à 10:45, Christian Quest a écrit :
> > HTTPS même 503 pour moi... le service ne semble plus opérationnel... :(
>
> Je pense qu'ils ont laissé tombé. Déjà, avant, ça ramait. Ça ne doit
> plus faire partie de leur business model.
>
> Eric
>
>
> >  > itoworld fournissait des cartes thématiques des données OSM dont
> la
> >  > carte des limites de vitesse :
> http://product.itoworld.com/map/124
> >  >
> >  > Un service alternatif?
>
> ___
> 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] Accès conditionnel

[althio]

pour avoir une seule valeur à la clé maxweight:conditional
et pour avoir "aux bus sauf desserte locale" :

maxweight:conditional=3.5 @ (Jul-Aug); none @ delivery
caravan:conditional=no @ (Jul-Aug)
bus:conditional=destination @ (Jul-Aug)

On Tue, 30 Jul 2019 at 15:16, Jérôme Seigneuret
 wrote:
>
> Bonjour,
> par défaut acces= yes donc c'est pas utile
>
> Pour simplifier voici ce que je mettrai
>
> bus:conditional = no @ (Jul-Aug)
> caravan:conditional = no @ (Jul-Aug)
> maxweight:conditional = 3.5 @ (Jul-Aug)
> maxweight:conditional = none @ delivery
>
> Bonne journée
>
> Le mar. 30 juil. 2019 à 15:06, David Crochet  a écrit :
>>
>> Bonjour
>>
>> Je serais partie sur çà :
>>
>> access=yes
>> access:bus=no@Jul-Aug
>> access:caravan=no@Jul-Aug
>> maxweight:3.5=no@Jul-Aug
>> maxweight:conditional=none@delivery
>>
>>
>> Cordialement
>>
>>
>> --
>> David Crochet
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Une secondary en zone de rencontre ?

[althio]

le au hasard, un truc du genre secondary=yes).
Soit avec les relations, comme cela est fait pour les autres
itinéraires (transport en commun, vélo, randonnée, ...)


Et le meilleur commentaire à propos du routage, à mon avis, par Phyks :
> Doit-on chercher à interpréter l'aménagement à ce point ? À mon avis, non. 
> C'est un aménagement de type "zone de rencontre" avec tout un cadre légal 
> associée et une pénalité au routage probablement justifiée pour du trafic de 
> transit. Si on annote différemment pour biaiser les routeurs, on tague pour 
> un outil, ce qui à mon avis ne fait que masquer le problème. S'il y a du 
> trafic de transit possible dans des rues parallèles encore moins adaptées, 
> c'est que le plan de circulation n'est pas correct et c'est à la puissance 
> publique d'agir, pas à OSM de chercher à masquer et corriger ces erreurs.

+1
(ou à OSM de détailler le plan de circulation dans les rues
parallèles, si besoin)

-- althio

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

Re: [OSM-talk-fr] Une secondary en zone de rencontre ?

[althio]

Je penche pour la décision de la précédente discussion :
"highway=living_street" sur la zone.

Jérôme :
> Les catégories sont là comme dans tous référentiel pour définir des grands 
> axes de circulation et définir les comment on veut que le traffic soit jugulé.
> C'est un réseau topologique on évite de casser le maillage

Jean-Yvon :
> Je croyais pourtant que la discussion avait penché pour ce qui est sur le 
> terrain c'est-à-dire living-street.
> La puissance publique a voulu casser le couloir à voitures, je ne vois pas 
> pourquoi osm ne reflèterait pas celà. En mettant juste une limite de vitesse 
> on perd l'information sur la priorité piéton.
> Si ça semble après une aberration sur la carte c'est bien une représentation 
> fidèle de la réalité.

+1 avec Jean-Yvon.

On reflète la réalité du terrain surtout.
Que ce soit pour un réseau automobile ou cyclable, quand il est
continu ou discontinu sur le terrain, il doit être décrit tel quel
dans OSM.
Et les réseaux cyclables discontinus, c'est courant. Les réseaux
automobiles discontinus, c'est plus rare, mais il ne faut pas les
ignorer ou les cacher sous le tapis. Et induire les moteurs de routage
en erreur.


Et pour étendre le sujet :

D'autre part, un autre point important de la discussion précédente,
c'est la mise à jour de la hiérarchie, la topologie du réseau routier.
C'est peut-être le bon moment pour se demander si le niveau de
classification attribué à ces routes est bien représentatif de
l'usage.

A mon humble avis, les voies de Montrouge devraient être classifiées ainsi :

primary:
D920 Avenue Aristide Briand
D906 Avenue Pierre Brossolette

secondary:
D62 Avenue Marx Dormoy
D50 Rue Gabriel Péri

tertiary:
D63a Avenue Jean Jaurès (elle vaut peut-être encore son secondary,
déjà c'est limite... Mais avec le réaménagement, elle devrait, sans
beaucoup de doute, passer en tertiary)
D63 Avenue de la République (qui pourrait se reprendre une partie du
trafic de D63a)
D128 Avenue Henri Ginoux
D61 Avenue Verdier
D59 Rue Maurice Arnoux

source : 
https://opendata.hauts-de-seine.fr/explore/dataset/comptages-routiers-sur-la-voirie-departementale-archive/
et mon interprétation du comptage trafic routier

-- althio

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

Re: [OSM-talk-fr] simples pictogrammes vélo, pas de voies dédiées [était: Uniformiser le wiki "Bicycle"]

[althio]

Phyks :
> Je comprends pas très bien l'intérêt du cycleway:lane=pictogram en
> complément du shared_lane. Ne serait-ce pas expliciter une valeur par
> défaut ? (j'ai du mal à imaginer un cycleway=shared_lane avec autre
> chose qu'une valeur cycleway:lane=pictogram).

Oui, le "cycleway=shared_lane" présente davantage d'intérêt.
Tandis que "cycleway:lane=pictogram" n'apporte pas grand chose.
... Pour les cas que je connais : je ne sais pas à l'étranger, ou dans
le futur. ^^

> [...] j'avais retenu :
> * cycleway > infrastructure
> * oneway:bicycle > droit d'accès
> [...]

+1

> Dans ton cas, j'aurais mis
> highway=* + oneway=yes + oneway:bicycle=no (si pannonceaux, cf plus bas)
> + cycleway:both=shared_lane + cycleway:left:oneway=-1.

OK, merci pour l'analyse et le conseil.

> Donc, dans le cas idéal (DSC marqué et pannonceaux sous les sens interdits) :
> cycleway:left=lane (ou shared_lane), cycleway:lane:oneway=-1 et 
> oneway:bicycle=no.
>
> S'il n'y a pas de pictogrammes au sol, pas de tags cycleway (mais 
> éventuellement oneway:bicycle=no).
>
> S'il n'y a pas de pannonceaux sous les sens interdits, pas de tag 
> oneway:bicycle=no (mais éventuellement des cycleway).
>
> C'est bien ça ? On le détaille comme ceci dans la page FR:Bicycle ?

Tes explications me semblent logiques, je suis curieux de voir comment
insérer cela dans la documentation.

-- althio

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

[OSM-talk-fr] simples pictogrammes vélo, pas de voies dédiées [était: Uniformiser le wiki "Bicycle"]

[althio]

Phyks  :
> Je viens de refaire une passe sur la page FR:Bicycle et ma proposition
> actuelle (avec les diffs visibles dans l'historique de la page) est sur
>
> https://wiki.openstreetmap.org/wiki/User:Phyks/FR:Bicycle
>
> J'ai tenté d'harmoniser les descriptions entre elles et avec la version
> anglaise.

Bonjour et merci pour le boulot de documentation et harmonisation.

J'ai une question sur une configuration : Sens unique, double-sens
cyclable, simples marquages avec pictogrammes des 2 côtés, mais pas
ligne pour voies dédiées.

Qu'est-ce qui s'applique ?

left:
Double-sens cyclable, dont une bande côté gauche de la route dans le
sens opposé uniquement. (= M3a)
Mais pas de voie dédiée, de simples marquages ou/et panneaux de
signalisations. (= S1)
right:
Bande cyclable du côté droit dans le sens de circulation générale. (= M1/M2a)
Mais pas de voie dédiée, de simples marquages ou/et panneaux de
signalisations. (= S1)

M1 : highway=* + oneway=yes + oneway:bicycle=no + cycleway:both=lane
M2a : highway=* + oneway=yes + cycleway:right=lane
M3a : highway=* + oneway=yes + oneway:bicycle=no + cycleway:left=lane
+ cycleway:left:oneway=-1
S1 : highway=* + oneway=yes + oneway:bicycle=no

J'imagine que S1 est la configuration qui représente bien la
situation, mais il semble possible aussi d'utiliser d'autres clefs :
"La clef cycleway:lane=* permet de préciser si la bande cyclable est
matérialisée par une ligne continue ou discontinue, ou de simples
pictogrammes."
Et là je découvre une autre page Key:cycleway:lane, avec des clefs
jamais utilisées dans le tableau de FR:Bicycle :
cycleway=shared_lane + cycleway:lane=pictogram

Alors, est-ce que ça serait correct de préciser :
S1 : highway=* + oneway=yes + oneway:bicycle=no + ...
et pictogrammes : ... + cycleway:both=shared_lane + cycleway:lane=pictogram

Est-ce que ça vaut le coup d'ajouter ce genre de configurations dans
le tableau, déjà long mais bien pratique, de FR:Bicycle ?

-- althio

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

Re: [OSM-talk-fr] question limite nb vues switch to osm

[althio]

0. Ce genre de site pourrait s'en sortir avec une carte statique ou
deux : plan de situation, carte d'accès plus large.
-> possible avec une carte OSM correctement attribuée, sans serveur de
tuile ou question de trafic.

0.bis. Le choix entre qualité OSM et qualité Google... vraiment le
château de Villandry c'est un cas d'école...
-> sans commentaire :
https://mc.bbbike.org/mc/?lon=0.513523=47.339801=17=4=mapnik=google-map=osmfr=digitalglobe-premium

1. Pour absolument avoir une carte dynamique..., on rentre dans les
critères "nombre de vues", ou autres...
Je pense que ça passe pour les sites confidentiels (quelques centaines
de vues/jour), les sites perso/associatifs avec une faible audience ET
une faible capacité à maintenir leur site web.

2. D'un autre côté, dès que c'est un site commercial, ou avec un
webmaster, ou avec des ressources, il faut étudier en priorité une
autre solution
* remplacement 1:1 de Google Maps par un fournisseur de tuiles sur
base OSM (un fournisseur, un service, un tarif)

3. Et finalement, pour une structure plus technologique, avec plus de
ressources (humaines ou financières), il y a la totale :
* bascule en autonomie et indépendance, avec une maîtrise des données
et des serveurs (le travail pour y aboutir peut être fait seul ou
accompagné par des prestataires)

cf. https://www.openstreetmap.fr/exitgmaps/

On Tue, 16 Jul 2019 at 07:45, Laurence P  wrote:
>
> onjour,
>
> lorsque je tombe sur un site web français qui propose une carte  Google hors 
> service (du fait que le site en question n'ait pas payé son obole à Google), 
> je leur envoie en général un email pour leur conseiller de passer à 
> OpenStreetMap.
>
> À partir de quel nombre de vues est-il judicieux de les orienter vers 
> https://switch2osm.org/fr/ ? Je sais qu'il y a les limites fixées par la 
> fondation OSM... mais qui dépend du trafic total OSM qui lui varie, je 
> demande juste une grosse fourchette :)
>
> Par exemple, dernier site repéré :
>
> https://www.chateauvillandry.fr/preparez-votre-visite/les-informations-pratiques/les-tarifs-les-horaires-les-acces/
>
> Merci d'avance de vos réponse.
>
> --
> Laurence
>
> ___
> 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] Attribution incorrecte

[althio]

Et pour la vérification de "l'infraction" : c'est oui.
Ils utilisent une carte avec des données OSM, sans attribution.

Et même double oui.
La carte est directement pompée sur les serveurs de la fondation OSM.

On Mon, 15 Jul 2019 at 23:12,  wrote:
>
> Je pense préférable que toute personne voyant un tel problème utilise le 
> modèle conçu par Deuzeffe et si la personne ne réagit pas coreectement qu'on 
> actionne le niveau officiel. En ne respectant pas l'attribution, c'est aussi 
> ton droit en tant que contributeur qu'ils bafouent.
> Marc ou Deuzeffe te retrouveront le lien si besoin.
>
> Jean-Yvon
>
>
> > Gesendet: Montag, 15. Juli 2019 um 23:04 Uhr
> > Von: "pepilepi...@ovh.fr - pepilepi...@ovh.fr" 
> > 
> > An: talk-fr@openstreetmap.org
> > Betreff: [OSM-talk-fr] Attribution incorrecte
> >
> > Bonjour,
> >
> > Sur
> > https://www.clevacances.com/fr/locationvacances/provencealpescotedazur/hautesalpes/saintveran-1905/appartement_65_m2_4_personnes_a_saint_veran_parc_naturel_regional_du_queyras_hautes_alpes/37581
> > j'ai la très nette impression de reconnaître "notre" OSM.
> >
> > Et l'attribution est à clevacances...
> >
> > Un "officiel" pour vérifier et au besoin leur rappeler leur obligation ?
> >
> > Merci, bonne soirée
> >
> > Jean-Pierre
> >
> > --
> > 
> >
> > 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
> >
>
>
> ___
> 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] piste cyclable connectée à un trottoir

[althio]

> Florian  :
> > traffic_signals=bicycle

marc marc :
> j'imagine que c'est https://www.openstreetmap.org/node/6400116392
> On peux avoir une photo du feu (sa lampe) ?
> cela permettrait de documenter cette valeur :)

Ou alors découper celle-là ;)
https://commons.wikimedia.org/wiki/File:Ampel-Kassel-02.jpg

Mais revenons un peu sur ce choix de tag :)

résumé "TLDR" :
j'ai fait mes devoirs, j'ai fait ma recherche, et je propose
maintenant, pour spécifier l'aspect cycliste-vélo :
cycleway=traffic_signals + [traffic_signals=signal]

[fin du "TLDR", vous entrez dans un long message de tagging]

Quand je vois la liste documentée sur le wiki, les valeurs proposées
https://wiki.openstreetmap.org/wiki/Key:traffic%20signals
ou les valeurs utilisées sur taginfo
https://taginfo.openstreetmap.org/keys/traffic_signals#values

j'ai bien du mal à voir l'intérêt et le sens de cette valeur
traffic_signals=bicycle.
Pour moi, c'est et ce sera encore :
traffic_signals=signal: a standard traffic signal, typically with
three steady aspects


Je reprends donc à la base de la documentation :
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals
highway=traffic_signals | Indicates traffic signals for cars.
crossing=traffic_signals | Indicates traffic signals for pedestrians.
Tout cela dénote une vision très centrée "voiture qui passe & piéton
qui traverse".

En fait, on pourrait plutôt considérer qu'il s'agit de "flux rapide"
(en highway=traffic_signals) et "flux traversant" (en
highway=crossing).
https://wiki.openstreetmap.org/wiki/Key:crossing mentionne la
possibilité que les vélos existent (mais pour traverser la grosse
route, pas pour être le flux rapide...)

Du coup, en flux rapide, il existe déjà :
sur le segment du flux rapide
- highway|railway=*
et sur le noeud à la jonction avec le flux traversant
- highway=traffic_signals + [traffic_signals=signal] (ou d'autres
trucs avec railway...)

et en flux traversant, on a :
sur le nœud à la jonction avec le flux rapide
- highway=crossing + crossing=traffic_signals|* + segregrated=yes|no +
bicycle=yes|no
avec plus de détails, on a aussi le segment du flux traversant
- highway=footway + footway=crossing
- et/ou highway=cycleway|* + bicycle=yes|designated + cycleway=crossing

(ouf...)

Dans cette idée, dans ce schéma-là, issu de la documentation actuelle,
mais pas du tout adaptée pour les cyclistes, je pense que la pièce
manquante, c'est pour le flux rapide à vélo :
sur le segment du flux rapide à vélo
- highway=cycleway|* + bicycle=yes|designated
sur le nœud à la jonction avec le flux traversant
- cycleway=traffic_signals + [traffic_signals=signal]

d'où ma suggestion "cycleway=traffic_signals", usage actuel : existant
mais négligeable

et...
tant pis pour le léger troll... j'espère faire comprendre ainsi mon
point de vue sur la vision destinataire ≠ type ≠ droit d'utilisation,
appliquée à votre sauce
[le troll rentre]
Quand je lis les définitions de traffic_signals=signal, blinker,
continuous_green...
Puis quand je vois ce tag traffic_signals=bicycle, j'imagine quoi ?
Le mécanisme qui régule le trafic et qui indique la priorité, c'est un
vélo, un vrai vélo réel, physique ?
[le troll sort]
Ou bien c'est un signal lumineux, standard, trois lumières, trois
couleurs. Donc "traffic_signals=signal".
Avec une forme de vélo.

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

Re: [OSM-talk-fr] Indiquer un croisement

[althio]

Julien djakk:
> Salut ! Regarde le cas sud-coréen ou japonais !

C'est ici :
https://wiki.openstreetmap.org/wiki/Named_spots_instead_of_street_names

Et... c'est le cas sud-coréen ou japonais !
C'est (très très) minoritaire en France, d'avoir des noms spécifiques
à de simples croisements/carrefours. Et où les noms des croisements
sont plus importants que le nom des rues.

Alors que une place, c'est significatif, en France et pays alentours.

>> avec https://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare
>>
>> C'est mon avis.

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

Re: [OSM-talk-fr] Indiquer un croisement

[althio]

> je me suis aperçu que la place Jean Jaurès à Montrouge n'était pas un
> élément en tant que tel.
> *Quelle est la meilleure méthode d'après vous pour indiquer une place / un
> croisement ?*
>
> 1. créer un polygone qui englobe tous les éléments de la place
>

avec https://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare

C'est mon avis.

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

Re: [OSM-talk-fr] piste cyclable connectée à un trottoir

[althio]

> traffic signal est suffisant dans ce cas car étant sur la piste qui est
réservée aux vélos
+1

Par défaut, ça marche bien :
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Tagging_also_cycleway_traffic_signals

> Je propose
> higway=traffic_signals
> traffic_signals=bicycle
>
> 2 utilisations, mais ça me semble cohérent par rapport aux autres valeurs
possibles

J'hésite, je ne trouve pas ça complètement cohérent.
https://wiki.openstreetmap.org/wiki/Key%3Atraffic_signals
Je trouve que traffic_signals=* essaie de décrire le mode de fonctionnement.

j'irai plutôt sur un format :
higway=traffic_signals (attribut de base) [suffisant dans 99%+ des cas ?]
traffic_signals=signal (optionnel, car valeur supposée par défaut)
traffic_signals:for=bicycle (optionnel, seulement pour les cas ambigus)
[note : inventé, 0 usage]

-- althio




On Fri, 28 Jun 2019 at 11:10, Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> Je propose
> higway=traffic_signals
> traffic_signals=bicycle
>
> 2 utilisations, mais ça me semble cohérent par rapport aux autres valeurs
> possibles.
>
> Le ven. 28 juin 2019 à 11:02, marc marc  a
> écrit :
>
>> Bonjour,
>>
>> Le 28.06.19 à 10:28, Florian LAINEZ a écrit :
>> > Une nouvelle piste cyclable
>> > <https://www.openstreetmap.org/way/683304588> vient d'être mise en
>> > service sur Ordener à Paris.
>> > Je l'ai connectée à un trottoir surfacique
>> > <https://www.openstreetmap.org/way/217028973> car c'est la réalité (un
>> > peu aberrante) du terrain.
>> > J'imagine que pour le routing, ça va pas vraiment le faire ... que
>> > conseillez-vous ?
>>
>> indépendamment de la précarité surfacique,
>> ce qui va surtout poser problème c'est que cette connexion
>> est actuellement interdite aux vélos dans osm : bicycle=no
>>
>> Quand le cycliste arrive au bout de la piste,
>> il met pied à terre ou il y a une connexion non renseignée ?
>>
>> > J'ai aussi créé un feu tricolore dédié aux vélo
>> > <https://www.openstreetmap.org/node/6400116392>. Y a-t-il un tag
>> > spécifique pour ça ?
>>
>> le tag highway=traffic_signals est le même pour piéton et voiture,
>> donc on peux garder le même pour les vélos.
>> Sur le "passage vélo" (le noeud commun voiture-vélo)
>> certain utilisent cycleway=crossing crossing=traffic_signals
>>
>> Cordialement,
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Florimond Berthoux
> ___
> 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] Josm - traduction wiki - ToogleDialog

[althio]

Oui, c'est bien ça.
On peut aussi l'exprimer en "activé/désactivé" ou "affiché/caché" selon le
contexte.

On Wed, 26 Jun 2019 at 17:07, lenny.libre via Talk-fr <
talk-fr@openstreetmap.org> wrote:

> Bonjour
>
> La page du wiki qui parle des fenêtres et des panneaux s'appelle
> https://josm.openstreetmap.de/wiki/Help/ToggleDialogs
>
> Deepl me traduit ToggleDialogs par "Dialogues à bascule" - bascule parce
> qu'on peut les dérouler/enrouler ou y a-t-il une autre explication ?
>
> Merci d'avance
>
> Leni
>
>
>
> ___
> 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] [Python] Générer image carte statique à partir coordonnées GPS?

[althio]

>
> De toute façon, vu que le service semble voué à disparaître, je vais
> regarder ailleurs.
>
> Hors-bande, on me suggère  Mapbox   .
>

Jawg
Makina Corpus
MapTiler
GeoFabrik
Gravitystorm Ltd
and.com
GEO-6
Mapbox
...
https://wiki.openstreetmap.org/wiki/FR:Services_commerciaux_bas%C3%A9s_sur_OSM
https://wiki.openstreetmap.org/wiki/Commercial_OSM_Software_and_Services
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] viennoiseries

[althio]

> oui, mais il semble qu'il soit question de viennoiseries et non de pain :)

ah bon ? et alors ?
les propositions suggérées par les protagonistes :
brötchenservice=yes
bakery_goods_delivery=yes
bakery=yes

tout ça, c'est de la boulangerie, ils cherchent à distinguer le lieu
de production et le lieu de vente.

je n'ai pas compris qu'ils cherchaient à distinguer une vente de pain
d'une vente de viennoiseries.

et au passage, pour Brötchen (=petits pains)
https://de.wikipedia.org/wiki/Br%C3%B6tchen

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

Re: [OSM-talk-fr] Version patché d'iD

[althio]

> NB: il se raconte en coulisse que la maquette aurait
> peut-être déjà atteint en partie son but, des commits
> d'annulation sorti de nulle part pour une partie des conflits
> ont été poussé à toute hâte sur le dépôt officiel et
> une version 2.15.2 est sortie en dehors de tout planning
> habituel en vert dans la liste ci-dessous
> https://github.com/openstreetmap/iD/commit/ff8e5bd5d3c7caae9e7f3202c2a5aceddb4a92db
> pas sur qu'on doivent attribuer tout cela à la maquette
> mais les 2 qui m'en ont parlé en privé m'ont clairement dit
> qu'il y avait une peur que la maquette prenne de l'ampleur

Oui, effectivement, avec un message assez révélateur que quelque chose
a fait bougé les lignes (la maquette, et/ou des pressions antérieures,
et/ou une décision des employeurs et financeurs).

https://github.com/openstreetmap/openstreetmap-website/pull/2267

===
Extrait et traduction semi-automatique
===

Mise à jour vers iD v2.15.2 #2267

bhousel a commenté il y a 15 heures -
Bonjour ! Nous avons beaucoup reçu de nombreux retours à propos des
nouvelles fonctionnalités de validation d'iD v2.15. Nous savons que
tout le monde n'approuve pas toutes les améliorations apportées [...]
nous avons donc décidé de revenir sur plusieurs des changements
controversés. Notamment :

- supprimé l'option autofix du validateur - les utilisateurs doivent
maintenant inspecter et décider de chaque problème détecté
individuellement.
- supprimé la possibilité d'attribut nonsquare=yes pour les bâtiments
non carrés .
- ajusté le libellé des messages pour utiliser une formulation plus
neutre lors de la mise à jour d'éléments avec lié à des marques.
- corrigé le bogue qui faisait que le validateur ajoutait barrier=kerb
lors de la mise à jour des balises highway=crossing.
- modifié les préréglages pour les quais et les plates-formes de
transport public pour ne plus ajouter highway=footway comme attribut
suggéré.

Nous sommes vraiment désolés pour les problèmes causés par la récente
mise à jour d'iD, et nous espérons travailler avec la communauté
OpenStreetMap pour que la carte soit la meilleure possible.

Merci, Bryan et Quincy.
(@bhousel et @quincylvania)

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

Re: [OSM-talk-fr] viennoiseries

[althio]

et bien, à la lecture de la page wiki anglaise
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbakery
je suggère :

shop=bakery (qui est un simple lieu de vente, dans sa définition stricte)
noname=yes
opening_hours=08:00-10:00
operator=camping xyz

et en optionnel, utiliser un tag pour différencier une boulangerie d'un
simple dépôt de pain.
craft=bakery pour une boulangerie

et en optionnel, inventer/détourner un tag pour différencier un simple
dépôt de pain d'une boulangerie.
no:craft=bakery ou oven=no ou ??? pour un dépôt de pain ???

On Mon, 17 Jun 2019 at 18:29,  wrote:

> Non ce n'est pas vous dire que des viennoiseries vous attendent à la pause
> café ;-).
>
> À un accueil de camping (Marc : amenity=reception_desk ;-=)) il y avait
> brötchenservice=yes.
>
> Le contributeur n'est pas d'accord pour modifier en breakfast=yes ou
> shop=convenience. Il irait plutôt vers une nouvelle clé
> bakery_goods_delivery.
>
> Je propose plutôt backery=yes.
>
> Qu'en pensez-vous ?
>
> Jean-Yvon
> ___
> 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] BDOrtho IGN en rade ?

[althio]

Bonjour Dominique,

Avant de te répondre (autant que je peux) et pour clarifier un autre aspect
pour tout le monde (il y a beaucoup de lecture...) :

> la mention de source « © IGN - année d'édition - copie et reproduction
interdite ».
Dans les grandes lignes, cela veut dire qu'on ne peut pas copier les images
de la BD ORTHO (depuis un éditeur OSM vers un autre document ou une autre
application).
Mais bien sûr la convention prévoit toujours d'autoriser le traçage de
données dans OpenStreetMap en s'appuyant cette imagerie.


Le cas proxy est effectivement un point particulier.
Ce point pourrait être redéfini explicitement si besoin, mais par défaut,
on devrait retomber sur les conditions d'utilisations générales (pour tout
ce qui n'est pas spécifié autrement dans la convention).

On passe alors sur :
http://professionnels.ign.fr/doc/CGU-ressourcesgeoportail.pdf
et ce qui nous concerne notamment :

> 2.1 OBLIGATIONS PROPRES AU LICENCIE
> Le licencié s’engage notamment :
> - [...]. Le stockage hors connexion internet par l’utilisateur ou le
licencié du contenu des ressources en ligne du Géoportail n’est autorisé
qu’aux seules fins d’améliorer la performance de fonctionnement de
l’application. L’usage dans ce contexte sera déclaré préalablement ;

Si l'IGN est toujours d'accord pour ce fonctionnement, nous continuous avec
le proxy.
Si l'IGN que les requêtes tombent toujours chez eux, il y aura quelques
changements techniques à étudier et à mettre en place.

Bien à toi

Benoît



On Wed, 12 Jun 2019 at 09:51, Dominique Rousseau  wrote:

> Le Tue, Jun 11, 2019 at 11:55:18PM +0200, Benoit Fournier [
> ben.fourn...@gmail.com] a écrit:
> [...]
> >
> > Pour un lien public qui semble plus amical si vous n'avez pas de compte
> sur
> > la plateforme Loomio :
> > https://www.loomio.org/d/QeyaurMn/nouvelle-convention-avec-l-ign
> > Mes excuses pour le premier lien, qui n'est pas pratique effectivement
> sans
> > inscription à Loomio.
>
> En tout cas, merci de diffuser l'avancement :)
>
> Moi, y'a un truc qui me fait réagir, en haut de la page 5, c'est la
> mention de source « © IGN - année d'édition - copie et reproduction
> interdite ».
> Je sais que ça veut dire qu'on a pas le droit d'effectuer de copie des
> images en elles-même, mais 1) c'est ce qu'on fait avec le proxy, et 2)
> ça peut faire "peur", rédigé comme ça, je trouve.
>
>
>
> --
> Dominique Rousseau
> d...@lee-loo.net - 06 82 43 12 27
>
> A l'instant où l'esclave décide qu'il ne sera plus esclave,
> ses chaînes tombent.  -- Mahatma Gandhi
>
> ___
> 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] éditeur ID

[althio]

>
> Version courte : oups.
> Autant pour moi : je vois que dans mes préférences utilisateur OSM j'avais
> mis en-US en fr-FR fr. En mettant fr-FR fr en-US en ça marche mieux ;-).
>

Si tu veux favoriser la version anglaise- britannique par rapport à la
version anglaise-américaine, ça peut se faire :
fr-FR fr en-GB en

Cet aspect-là de iD (versions et traductions) est plutôt bien implémenté.
Certes l'anglais-américain est la langue de développement et
l'anglais-par-défaut.
Mais la version britannique co-existe dans les traductions, avec toutes les
autres langues.
(de même qu'on pourrait imaginer plusieurs variétés de français pour les
différentes zones francophones)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dépose-minute

[althio]

Je reste sur mon candidat :
highway=service + service=drop_off
+ fee... + maxstay...

cf: https://lists.openstreetmap.org/pipermail/talk-fr/2018-January/087452.html

-- althio

On Fri, 5 Apr 2019 at 11:34, Noémie Lehuby via Talk-fr
 wrote:
>
> Hello,
>
> Je n'ai rien trouvé sur le sujet dans le wiki : comment cartographier un 
> dépose-minute, d'une gare ou d'un aéroport par exemple ?
>
> Je dirais
> si c'est un parking : amenity=parking + kiss_ride = yes
> parce que dépose minute se dit "Kiss & Ride" en anglais, et en miroir de 
> park_ride qu'on utilise pour les parking relais.
> Il y a quelques très rares occurrences de kiss_ride = * et de 
> capacity:kiss_and_ride dans OSM.
>
> si c'est une voie de circulation (ce qui est à mon avis le cas le plus 
> fréquent) :
> highway=service + service=kiss_ride ?
>
> --
> nlehuby
>
> ___
> 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] licence coordonnées géo depuis OSM

[althio]

Précautions d'usage : je ne suis pas avocat spécialiste en licenses et
propriété intellectuelle.

Mon humble avis personnel :

Le cas d'usage, c'est (presque) du geocoding (à la sauce geocoding manuel),
qui consiste à retrouver des coordonnées dans la base OSM ou avec un outil
qui s'appuie sur des données OSM.
lecture de référence pour ce cas d'usage :
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline

A noter d'emblée : dans le cas particulier du geocoding pur, l'obligation
d'attribution est levée.
> A geocoded database need not maintain attribution attached to the
database, provided it is not a Derivative Database

Pour la question de la license de la base constituée, toute la discussion
va porter sur l'étendue des données utilisées, "substantial extract" ou pas
> A collection of Geocoding Results [is OR is not] a substantial extract of
the OSM database [if]

Dans votre cas d'usage, il me semble (a priori) que l'on se place dans
cette configuration :
> a systematic attempt to aggregate all or substantially all Primary
Features of a given type [...] within a geographic area city-sized or
larger.

Donc, on reste dans le fonctionnement par défaut : Partage à l'identique,
la base combinée avec les coordonnées (Collective Database) est en ODbL
(alors que la base initiale, sans les coordonnées, garde sa license). Il
faudrait donc publier les deux bases avec deux licenses différentes : sans
les coordonnées publié sous license ouverte et avec les coordonnées publié
sous license ODbL.

Sauf si l'étendue des données utilisées est réellement non significative
"not a substantial extract".
Il faut alors combiner la lecture de :
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Geocoding_-_Guideline
 et
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline

Dans les cas suivants, l'usage est jugé non significatif :
- only [...] latitude/longitude information are included in the Geocoding
Results, and
- less than 100 Features, or
- the geographic area is small, corresponding to an area of up to 1,000
inhabitants.

Alors on passe dans le fonctionnement allégé : toujours aucune attribution
(cas spécial du geocoding) et aucune obligation sur la license de la base
constituée, qui peut garder la license de la base initiale.

Dernière considération :
Puisque l'on est dans le cas d'une recherche très manuelle, directement sur
la carte, on peut envisager plusieurs cas :
- une recherche par nom ou adresse, grâce au géocodeur (Nominatim) intégré
sur le site openstreetmap.org, et/ou
- une recherche visuelle, directement sur la carte
et
- l’élément est déjà présent et affiché sur la carte du site
openstreetmap.org, ou
- l'élément n'existe pas dans OSM.

Si l'élément n'existe pas dans OSM, mais que les coordonnées sont
simplement pointées sur la carte à son emplacement (vide !), cela ne compte
pas comme une extraction de données de la base OSM.
Mais ce serait bien d'ajouter une note OSM au passage pour signaler ce
manque ;)

Au final :
- il faut évaluer la taille et la population de la région concernée (plus
ou moins de 1000 habitants)
- il faut évaluer le nombre d’éléments impliqués (plus ou moins de 100
éléments retrouvés par une recherche en s'appuyant sur des données OSM)
- il faut tout relire avec un service juridique ou un avocat spécialisé

-- althio

On Tue, 2 Apr 2019 at 18:06, Magalie Dartus  wrote:

> Bonjour,
>
> Je suis en train de constituer des jeux de données "équipements publics"
> avec certaines collectivités pour les publier en open data et la question
> est de savoir comment récupérer les coordonnées gégraphiques.
>
> J'aimerai rediriger les éditeurs de données des collectivités vers OSM en
> leur proposant d'ouvrir la carte/faire un clic droit/afficher
> l'adresse/copier les coordonnnées/coller dans le jeux de données open data.
>
> L'éternelle question est : si on fait ça, est-ce que le jeu de données
> "équipements publics" passe en licence ODbL?
>
> A votre avis
>
> Magalie
> ___
> 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] bac à marée

[althio]

Le problème, c'est que l'utilisation d'un seul terme sera toujours
plus ou moins ambiguë, difficile d'inclure chaque spécificité, de
chaque ville, de chaque plage, pour savoir ce qui est accepté ou non
(déchets humains, bois (naturel ou non), déchets naturels, ...)

Pourquoi pas une liste plus détaillée ?
amenity=waste_disposal
+ waste=trash;cordage;fishing_nets;glass;plastic;rubble;cigarettes;clothes;shoes
+ description:fr=Bac à marées. Pour la collecte des cordages, des
filets de pêche, du verre, des emballages, plastiques, mégots,
chaussures et vêtements. Ne pas ramasser les débris naturels (animaux
morts, végétaux, bois).
[ + (???) no:waste=organic;green_waste;wood ]

On Tue, 2 Apr 2019 at 07:54, erwan salomon  wrote:
>
> je voudrais ajouter les bacs à marée près de chez moi
> quelques associations poussent pour en installer avec l’accord des mairies 
> locales, parfois ce sont les mairies qui les installent d’elles mêmes :
> https://lorient.maville.com/actu/actudet_-pres-de-lorient.-trois-bacs-a-maree-installes-aux-abords-des-plages_52713-3681885_actu.Htm?fbclid=IwAR2B0zqpTlaGVxtXiTuJV6FbmLC9Yu9_InnRyZyXkk-azYXVC-6OlqbpAtE
>
> pour ceux qui ne connaissent pas
> il s’agit généralement de bacs (genre 1m x 1m de 0,5-1m de haut), souvent en 
> bois/palettes
> il servent à ce que les gens qui se baladent sur les plages ramassent les 
> détritus qui trainent sur les plages
> ces détritus sont en fait les déchets qui flottent dans la mer qui se 
> déposent au gré des vents en marées (la laisse de mer : des algues et animaux 
> morts qu’on laisse sur la plage, c’est un biotope naturel, et des plastiques 
> et autre, petit ou gros comme des filets de pêche …)
> selon les cas, soit une asso s’occupe de vider les bacs pour amener en 
> déchêterie, soit c’est les éboueurs directement
>
> il ne semble pas y avoir de cas précisés dans OSM (y’a bien des 
> waste_disposal en bordure de plages qui en sont peut-être ?)
> en toute logique ça devrait être :
>
> amenity=waste_disposal
> +
> waste=mixed (47 selon taginfo, mais pas spécifique)
> ou
> waste=tidewrack (0 occurence, j’aime bien mais ça représente les déchet et le 
> varech soit toute la laisse de mer)
> ou
> waste=beach_litter (0 occurence, semble ne regrouper que les déchets donc 
> plus juste, mais je préfère éviter les espace autant que possible)
>
> j’aimerai bien avoir votre avis avant d’en intégrer et d’en parler aux 
> associations qui sont activent dans le ramassage mais qui connaissent peu OSM
> ___
> 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] Quel tag pour les bureaux d'une commune

[althio]

vincent :
office=government
(https://wiki.openstreetmap.org/wiki/FR:Tag:office%3Dgovernment)
> (les gens ne sont pas employés par le gouvernement ? ou alors government est 
> un faux-ami ?).

Oui, faux-ami.
Pour dire "collectivité territoriale" ou "collectivité locale",
l'anglais peut être "local government" ou "local authority".

Les pages du wiki:fr ou wiki:en sont plutôt claires et justes sur l'utilisation
> office = government
> Description
> Un bureau d'une agence ou d'un département gouvernemental (supra)national, 
> régional ou local.

Mais... si tu parles de bureaux d'ACCUEIL du public (et pas seulement
de bureaux de travail, fermés au public), il faut chercher si les
attributs ne peuvent pas être complétés par quelque chose en
amenity=townhall/* ou access(?)=* pour faire la distinction.

-- althio

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

Re: [OSM-talk-fr] Dessiner bande de part et d'autre d'une ligne ferroviaire ?

[althio]

L'outil qui me semble adapté, c'est QGIS. Un outil spécialisé pour
l'analyse spatiale., mais il y a de la prise en main à prévoir.
https://qgis.org

Avec des plugins à considérer pour les données OSM
(https://plugins.qgis.org/plugins/OSMDownloader/ ;
https://plugins.qgis.org/plugins/QuickOSM/) et les itinéraires et
isochrones (https://plugins.qgis.org/plugins/ORStools/)


Ou bien le service ORS - OpenRouteService, qui fait les isochrones
autour d'un point et en bonus le calcul de population.
https://maps.openrouteservice.org/reach?n1=48.801162=2.282853=15=48.801006,2.283759=2=0=10=5=en-US=km

On Tue, 26 Mar 2019 at 12:14, Shohreh  wrote:
>
> Bonjour,
>
> Afin d'estimer combien de gens y ont accès, j'aimerais dessiner une bande
> d'une largeur de 2km de part et d'autre d'une ligne de tram  :
>
> https://ibb.co/9wJjbKj
>
> Existe-t-il un moyen de programmer ça en partant de la relation d'une ligne
> ferroviaire ?
>
> Merci.
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Des projets de construction pas sorti de terre !

[althio]

>
> Petite question : peut-on récupérer facilement tous les changesets
> "commentés"  d'un contributeur ?
>

Sur la page http://hdyc.neis-one.org/?L3mp1ck4
le lien
> Discussed own changesets: 9
mène à
http://resultmaps.neis-one.org/osm-discussion-comments?uid=3941729

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

Re: [OSM-talk-fr] Overpass API en grève

[althio]

Merci à toi Roland pour tout ton travail et ton annonce sur la liste
talk-fr !

Benoît


On Thu, 21 Mar 2019 at 21:06, Roland Olbricht 
wrote:

> Bonjour,
>
> l'Overpass API a returnée à operation normale.
>
> Je veux remercier l'association OpenStreetMap France pour la traduction
> de l'information sur la problème a
> https://www.openstreetmap.fr/copyright-article-13/
>
> Roland
>
> ___
> 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] Les portes de Paris

[althio]

Presque pareil que Jean-Yvon pour moi :

> > Place=locality n'est pas un point, c'est un lieu sans habitant, les
> (quartiers) des "portes" de Paris sont maintenant habitées.
> Et actuellement personne n'habite sur une porte.
> Donc locality me va bien. Si par contre des quartiers s'appellent du nom
> de la porte d'à côté alors il faut mettre un contour et
> suburb/neighbourhood/quarter.
>

Un point avec place=locality : très bien pour les véritables lieux des
"Portes".
Je préfère un point, mais à la limite pourquoi pas un polygone qui englobe
les voies, le carrefour, de manière très étroite, mais pas les bâtiments.
C'est le point exact si on vise une navigation avec cette destination ou un
passage par ce point.

Un point (ou un polygone qui englobe les habitations du quartier) avec
place=suburb/neighbourhood/quarter : si et seulement si il y a un véritable
quartier avec une existence locale, qui répond à ce nom.
Pour Porte d'Orléans, tout à fait, il me semble que c'est suffisamment
reconnu pour être un nom de quartier ("J'habite à Porte d'Orléans", en plus
des commerces, aménités et arrêts de transport en commun qui reprennent le
nom).
Il y aurait quand même un travail de recensement des portes et de leur
reconnaissance en tant que quartier, pour affecter le bon niveau de
place=suburb/neighbourhood/quarter aux lieux qui pourraient en
bénéficier... et puis estimer leur "centre" ou leur "périmètre".

On Sun, 17 Mar 2019 at 11:13, djakk djakk  wrote:

> Salut !
>
> Un peu perdu dans toutes les sous-discussions, j’en relance une :)
>
> C’est moi qui avait initié la cartographie des portes de Paris.
> Actuellement c’est le nom d’un carrefour, souvent marqué sur les panneaux
> routiers. Mais certaines portes sont très proches les une des autres : si
> la Porte d’Orléans peut être le nom du quartier, la porte de Montrouge
> toute proche n’en est pas un. Elle ferait partie du quartier « porte
> d’Orléans » .
>
> @+
> Julien « djakk »
> ___
> 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] Quartiers à Paris

[althio]

marc marc :

De: "althio"
 > si quelqu'un veut supprimer le quartier administratif

c'est une caricature surement volontaire pour provoquer
les partisans de l'inverse mais cela n'a aucun sens.
[…]
c'est déjà parfois difficile de se comprendre sans 2ieme ou 3ieme degré,
alors évitons les :)


Vincent de Château-Thierry :


Donc le fait qu'une donnée n'aie "aucune existence de terrain" et/ou se
"retrouve en open data" serait une raison suffisante pour la saccager dans
OSM : renommage inconsidéré, suppression... Avec une logique pareille, […]


Effectivement, mea culpa, je retire ce que j'ai écrit.
J'aurais pu entourer ces passages avec des balises "ironie", "provocation"
ou "troll", ajouter des smileys… et au final j'aurais du m'abstenir tout
simplement.
En outre, la vérité est que je ne me moque pas tout à fait de ces données
de limites administratives.

Là où je suis rassuré, c'est qu'il y a du monde pour les défendre :)



D'un autre côté, des données ont été effacées pour de vrai, dans une autre
gamme de provocation, ont échauffé les esprits et font dépenser beaucoup
d'énergie dans ces discussions.
Je vais profiter du week-end pour souffler un bon coup ;)


En élargissant, je pense que tous les découpages ont leur place dans OSM :
administratifs, religieux, militaires, académiques et j'en passe, dès lors
qu'on dispose d'une source précise et compatible pour leur délimitation.


Un avis sur les quartiers qui n'ont pas de délimitation, sans source
précise ? C'est un des gros sujets de ce fil, et on demande l'avis de tout
le monde.

Bonne soirée et bon week-end à tout le monde.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[althio]

> En représentation cela donne ceci aujourd'hui
https://overpass-turbo.eu/s/GZD

Je trouve cette représentation utile et la richesse des données géniale.
Elle me donne envie de vérifier ou d'ajouter d'autres quartiers, mais pas
d'en supprimer.
Je ne vois aucun doublon.

Et si quelqu'un veut renommer le quartier administratif de la Goutte-d'Or
en :
name=Quartier administratif de la Goutte-d'Or
ou name=71e quartier administratif
ou name=administratif_police_7511871
Franchement... ça ne me dérange pas, ce truc n'a aucune existence de
terrain.
On pourrait aussi faire des articles et des identifiants wikidata
différents pour le "quartier administratif de la Goutte-d'Or" et le
"quartier de la Goutte-d'Or", ce n'est pas la même chose. Vraiment.
Je répète : ce n'est pas la même chose.
Et si quelqu'un veut supprimer le quartier administratif parce que [insérer
ici une raison quelconque]... je dis "pourquoi pas", de toute façon c'est
de la donnée de référence, on la retrouve en open data.

Par contre, si quelqu'un commence à supprimer des quartiers (au sens
commun), des noeuds place=*, ça ne va pas.
On bascule dans la destruction de données de réel contributeur, de terrain,
ou de connaissance locale.
Une donnée qu'il est difficile de trouver (un peu sur wikipedia) mais
surtout présente dans la mémoire collective.

> La page wikipédia
https://fr.wikipedia.org/wiki/Quartier_de_la_Goutte-d%27Or ne m'aide pas
plus.

Même pas cet extrait ?
> Historiquement, et dans le langage courant, « la Goutte d'Or » fait
généralement référence au sud-ouest du quartier administratif, autour de la
rue de la Goutte-d'Or, entre le boulevard Barbès et les voies ferrées.

Et si on reste sur wikipedia, on a beaucoup de choses à lire...

Par exemple le quartier d'à côté :
https://fr.wikipedia.org/wiki/Ch%C3%A2teau_Rouge_(quartier_de_Paris)
> Château Rouge est un quartier de Paris [...]. De nature informelle, il
fait partie des quartiers administratifs de la Goutte d'Or et de
Clignancourt.

Donc dans le quartier administratif de la Goutte-d'Or, on trouve le
quartier (non-administratif) de la Goutte-d'Or et une partie du quartier
(non-administratif) de Château Rouge.

Sur un autre quartier encore, Batignolles, on trouve la distinction
quartier administratif et quartier (non-administratif)
https://fr.wikipedia.org/wiki/Quartier_des_Batignolles
> Le quartier administratif des Batignolles est délimité [... définition de
l'étendue]
> Aujourd'hui les Batignolles apparaissent souvent comme [... étendue
significativement différente]

Un autre quartier, aucun lien direct avec un quartier administratif :
https://fr.wikipedia.org/wiki/Faubourg_Saint-M%C3%A9dard
> Le faubourg Saint-Médard ou "quartier Mouffetard" est un quartier de
Paris dans le 5e à cheval sur les quartiers administratifs Jardin des
Plantes et Val-de-Grâce.
idem pour le Marais
https://fr.wikipedia.org/wiki/Le_Marais_(quartier_parisien) et
https://fr.wikipedia.org/wiki/Quartier_du_Temple
> Le Marais est un quartier parisien historique (et non pas quartier
administratif)
idem pour https://fr.wikipedia.org/wiki/Quartier_latin_(Paris)
idem pour https://fr.wikipedia.org/wiki/Olympiades_(quartier_parisien)

Pour certains arrondissements, le travail de détails des quartiers est
avancé :
https://fr.wikipedia.org/wiki/13e_arrondissement_de_Paris#Quartiers
https://fr.wikipedia.org/wiki/12e_arrondissement_de_Paris#Quartiers

Toujours sur wikipedia, un article plus général
https://fr.wikipedia.org/wiki/Quartier_de_Paris
> la notion de quartier prend plusieurs significations à Paris :
> dans le langage courant, un quartier désigne un espace urbain pourvu
d'une identité commune sur le plan architectural, social, fonctionnel mais
délimité sans précision : le quartier latin, le Marais, le quartier
asiatique [...].
> dans le champ administratif, chacun des vingt arrondissements est découpé
en quatre quartiers.
> enfin, la mise en place des conseils de quartier s'est basée sur un
nouveau découpage de l'espace parisien en 121 quartiers
[carte des conseils de quartier, pour consultation :
https://www.apur.org/sites/default/files/documents/54.pdf si quelqu'un veut
s'amuser à superposer quartier administratif de la Goutte-d'Or et
périmètres des conseils de quartiers sur la zone...]
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[althio]

> Le 13 mars 2019, Florimond Berthoux a écrit :
>
> > Vaut mieux un centre imprécis, que pas d'infos du tout.
> > De toutes manières calculer un centre précis est absurde, voire impossible.
> > Nous ne faisons pas des cartes que pour les ordinateurs.

+1

Et encore, je dirais que, à l'échelle où ces infos sont intéressantes
(repérage de quartiers ou de lieu-dits dans une région plus vaste,
urbaine ou rurale), la modélisation par un repère ponctuel est la
meilleure solution.

Marc, Léo et quelques autres :
> en résumé : je suis pour l'ajout s'il a un consensus permettant d'en  définir 
> l'étendue. ajouter une info qui provoque des réponses parfois  fausse 
> impossible à corriger, c'est pire que ne pas avoir l'info.

Je trouve que tu décris un problème de consommateur de données
(Nominatim) qui fait des approximations ou des hypothèses
pragmatiques, mais pas toujours correctes, ou une présentation mal
adapté de ces résultats.
Je ne vois pas pourquoi on ne devrait pas garder ces points. On peut
les passer à des polygones SI c'est possible, d'accord. Les garder en
points, sinon. Les supprimer, pas d'accord.

> Le problème pour les quartiers c'est que les tags sont sur un node donc 
> impossible de savoir la taille de quartier, il n'y a pas moyen de le déduire 
> de quoi que ce soit pour le rendu.

Il y a tout de même une gradation dans les niveaux de place=* pour
l'importance des quartiers.
Et puis la taille d'un quartier dense ou d'un quartier étendu, ça ne
va pas tout régler non plus.

> Je pense qu'on devrait ignorer "l'avis des gens".

Argh ! On est dans OpenStreetMap, c'est un projet par les gens, pour les gens.

> Même si ce n'est pas OpenAdministrationMap, il y a une certaine "rigueur" de 
> terrain à conserver. Hors, comme il est impossible de délimiter précisément 
> un "quartier usuel", le point qu'on plaçerait pour l'identifier ne serait 
> qu'une information approximative et donc peu fiable.

Vouloir un polygone quand il n'y pas de définition administrative (cas
de tous les quartiers "informels" et les lieu-dits), on est d'accord,
c'est inadapté.

Refuser d'indiquer les quartiers parce que "la modélisation ne vous
convient pas", "on n'indique pas les choses avec des contours flous",
"c'est subjectif", "c'est une info qui provoque des effets parfois
bizarres dans certains outils", "c'est pas assez précis" : je trouve
que vous vous trompez de bataille.

Je trouve que c'est une vue jusqu'au-boutiste et contre-productive de
vouloir pousser la "qualité des données" à des critères inatteignables
ou hors de proportion. La "bonne qualité" ce n'est pas quand on a
enfin placé le point central d'un quartier usuel, après un sondage de
1000 personnes et des relevés au GPS haute précision. La "bonne
qualité" ce n'est pas quand on supprime une information de la carte
alors qu'il y a un consensus local pour estimer que une représentation
correcte et suffisante.

Le niveau de qualité intéressant, c'est quand on fournit une information utile.

-- althio

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

Re: [OSM-talk-fr] Quartiers à Paris

[althio]

Bon et bien merci Marc et Florimond ^^

C'est le meilleur résumé (par Marc) de notre point de vue :

> il y a 2 choses "renseignable" :
> la limite administrative et le lieu-dit
> mais l'un n'est pas l'admin_center de l'autre

et la meilleure explication (par Florimond) de notre point de vue :

> 1. Il faut les limites du quartier administratif, car c'est une réalité qui 
> est possible de trouver sur le terrain et est pratique.
> Sans admin_centre car il n'y a pas de lieu institutionnel qui le gère (pas de 
> chef de quartier qui travail dans le bureau du quartier).

> 2. Il faut définir les quartiers usuels, réalité du terrain, les gens se 
> disent habitant de tel quartier.
> Ces quartiers sont différents des quartiers administratifs, les dénomination 
> ou périmètre sont différents.
> Ils n'ont pas un périmètre bien défini (donc pas de frontière a tracer), il 
> faut les représenter par un nœud central au quartier.
> Ce nœud n'est pas l'admin_center d'un quartier administratif.

et la modélisation possible est :

1. un truc compliqué et administratif
Relation: type=boundary + boundary=administrative + admin_level=10 +
name=Quartier de * + ref:INSEE=7511871 + membres de la relation pour
définir la géométrie
(pas de membre admin_center)
(optionnel un membre label)

2. un truc simple et humain
Point: place=suburb|* + name=*
(pas d'admin_level, pas de ref:INSEE, pas de relation)


Romain,

Tu parles de chronologie d'insertion dans OSM entre deux éléments.
- Mais si les deux éléments ont une raison valable d'exister, la date
de création de l'un ou l'autre objet a peu d'intérêt.
- Si au contraire, ils sont redondants, ils devraient fusionner en
gardant le meilleur des deux éléments (géométrie, attributs,
historique de contribution)
Bien sûr, pour moi le nœud n'est pas en doublon de la relation.

Enfin, hors OSM, dans la réalité, la chronologie est intéressante : le
lieu-dit ou quartier existe *avant* le quartier administratif, et il
lui prête son nom.
Par exemple, le quartier de la Goutte-d'Or existe avant 1860, avant
d'être rattaché à Paris, avant la création du quartier administratif.

Les quartiers administratifs pourraient être redécoupés, renommés, le
18e arrondissement pourrait retrouver son "indépendance" en tant que
commune de "La Chapelle" ou être rattaché à une autre commune...
Tout cela changerait peut-être la Relation: type=boundary +
boundary=administrative + admin_level=10 et son name* ...
Mais tout cela ne changerait rien pour le lieu-dit et notre noeud place=* :
l'appellation "quartier de la Goutte-d'Or" serait toujours dans les
esprits, et pendant un certain temps.

-- althio

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

Re: [OSM-talk-fr] Quartiers à Paris

[althio]

Désolé de le dire un peu sèchement, mais pour l'instant, ne touchez à rien
sur les quartiers de Paris, surtout sans discussion préalable.
>:(

Pour des arguments, il faudrait commencer à lire les réponses sur le fil
qui a dévié, Bretagne - Loire-Atlantique - Goutte-d'Or.

Je veux bien vous faire un service avec un résumé ou bien les extraits
importants, au moins 2 ou 3 personnes ont tenté d'expliquer déjà. Mais pas
ce soir.

Pour la modification de Romain, j'étais contre. Je la trouve destructive
d'informations et irrespectueuse dans la manière. Je suis d'accord avec la
correction de Florimond, comme déjà expliqué.

Pour la modification de Jean-Yvon, je suis contre et je suppose qu'on
ferait mieux de faire également la correction inverse. Même si l'impact est
moindre, elle n'apporte rien à mon avis, sinon brouiller la réalité et la
sémantique.

Et arrêtez de toucher aux quartiers de Paris avant que cette discussion ne
soit tirée au clair.

-- althio

PS:
La discussion c'est bien.
Arrêtez de toucher aux quartiers.


On Tue, Mar 12, 2019, 21:56  wrote:

> Typiquement ce nœud devrait être l'admin_centre de la relation.
>
> Je l'ai ajouté comme ça vous devriez être contents tous les deux.
>
> C'est ce qui sert à afficher "La Goutte d'Or" sur la carte.
>
> Et les membres outer/inner de la relation c'est ce qui sert à afficher les
> contours.
>
> C'est exactement le problème qu'avait Waxy/Steph' pour la commune de
> Dembéni (ou Dembeni, j'ai vu les deux).
>
> Jean-Yvon
> Le 12/03/2019 à 21:24, Romain MEHUT - romain.me...@gmail.com a écrit :
>
> Bonsoir,
>
> J'ai constaté que Florimond a restauré le noeud que j'avais supprimé
> portant les tags name=Goutte d'Or et place=suburb cf.
> https://www.openstreetmap.org/node/2142414234 Il a précisé "Revert, il
> n'y a pas de doublon, le quartier adiminstratif n'est pas le quartier usuel"
>
> Je ne veux pas rentrer dans une guerre d'édition mais je veux juste
> comprendre.
>
> Chronologiquement parlant, ce noeud a été créé il y a 6 ans alors qu'un an
> avant existait déjà la relation
> https://www.openstreetmap.org/relation/2195145
>
> Ces deux objets font référence au quartier de la Goutte d'Or. Aussi, le
> noeud est bien à l'intérieur du périmètre définie par la relation.
>
> Donc, en quoi le noeud n'est pas en doublon de la relation ? Le noeud
> serait-il voulu juste pour avoir le rendu du nom du osm.org ?
>
> Romain
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les maternités ?

[althio]

mes premières idées c'est :

healthcare:speciality=maternity
healthcare:speciality=gynaecology
healthcare:speciality=obstetrics
(soi-disant, healthcare:speciality=gynaecology, ça fait les 2...
Gynécologie—obstétrique,
mais bon, on peut détailler, un, l'autre, ou les deux, il me semble)
(because dans la base FINESS => [03] Gynécologie, obstétrique,
néonatologie, réanimation néonatale)

et mon idée suivante c'est :
amenity=hospital | clinic | doctors
+ healthcare:speciality=gynaecology;obstetrics;maternity

mes idées d'après, c'est qu'on aurait bien besoin d'un projet dédié ou
d'une analyse Osmose si ça peut être proposé à l'intégration :)

-- althio


On Tue, 12 Mar 2019 at 09:31, Mathias Vadot 
wrote:

> Bonjour,
> je n'ai pas trouvé le tag correspondant aux maternités sur les différentes
> pages du wiki.
> Sur Paris j'ai bien trouvé une maternité mais non taggué... des idées ?
> Mathias
> https://urlz.fr/990d
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>  Garanti
> sans virus. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
> <#m_-4692075126938459525_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Les contours de la Bretagne

[althio]

Par contre, je ressens le besoin d'avoir ces deux entités.

1. le quartier "historique", connu localement, celui qu'on va
t'indiquer si tu demandes ton chemin
indiqué dans OSM avec place=suburb|neighbourhood|*
https://wiki.openstreetmap.org/wiki/FR:Tag:place=suburb
> zone importante d'une ville (place=town) ou d'une agglomération (place=city) 
> ayant un nom et une identité locaux distincts et reconnus. Les frontières des 
> zones urbaines (suburbs) peuvent être floues, des zones urbaines peuvent se 
> recouvrir
'Historiquement, et dans le langage courant, « la Goutte d'Or »' :
voir la note dans
https://fr.wikipedia.org/wiki/Quartier_de_la_Goutte-d%27Or

2. le quartier administratif, découpé à la serpe, défini par ses
limites et un code INSEE... et qui reprend parfois nom historique,
avec un vague recouvrement géographique. Inconnu localement, utile
pour les élections, statistiques et autres découpages artificiels.
indiqué dans OSM avec boundary=administrative + admin_level=10|* +  ...

2 entités, 2 élements.
De mon point de vue, aucun problème dans OSM (à part le tag wikidata...).

Il est possible de supprimer le tag wikidata sur une des deux entités.
Voilà un candidat au revert : https://www.openstreetmap.org/changeset/45240429
Il est possible de créer la référence wikidata pour le quartier historique.

-- althio

On Mon, 11 Mar 2019 at 11:41, Romain MEHUT  wrote:
>
> "On" ? Sauf erreur, seul Florimond a discuté dans ce sens.
>
> Ce serait pareil encore pour https://www.openstreetmap.org/relation/2195026 
> et https://www.openstreetmap.org/node/2143885542 Dans les 2 cas, il s'agit 
> bien de définir un quartier (en plus le tag wikidata est identique) et si on 
> suit https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element il 
> n'y a pas lieu d'y avoir deux objets.
>
> Romain
>
> Le lun. 11 mars 2019 à 11:09, djakk djakk  a écrit :
>>
>> Bah pourquoi ? On disait justement que ce ne sont pas les mêmes objets 
>> (administration contre habitude)
>>
>> Julien “djakk”
>>
>>
>> Le lun. 11 mars 2019 à 10:03, Romain MEHUT  a écrit :
>>>
>>> Bonjour,
>>>
>>> Au risque "d'échauffer" les échanges, j'ai supprimé les 2 noeuds "Goutte 
>>> d'Or" et "Clignancourt" conformément à ce principe 
>>> https://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element
>>>
>>> Romain
>>>
>>> Le dim. 10 mars 2019 à 23:38, Florimond Berthoux 
>>>  a écrit :
>>>>
>>>> Je complète:
>>>> « les 80 quartiers de Paris ont une définition précise pour leurs limites »
>>>> définition qui a été arbitrairement décidé par une instance 
>>>> administrative, qui n'est même pas présente sur le terrain.
>>>> Un parisien ne parlera par de l'ouest de la porte de la Chapelle comme 
>>>> étant la Goutte d'Or ;)
>>>> Donc non, au contraire c'est un bon exemple.
>>>>
>>>> Si le centre d'une région est mieux définit que ses limites extérieurs (ce 
>>>> qui est généralement le cas en histoire, les frontières bougent plus que 
>>>> le centre d'un territoire).
>>>> Il me parait tout à fait opportun de modéliser cette région par son 
>>>> centre. Modélisation certes imparfaite mais qui permet tout de même de 
>>>> situer la chose sans trop de subjectivité.
>>>>
>>>> Le dim. 10 mars 2019 à 19:03, Vincent de Château-Thierry 
>>>>  a écrit :
>>>>>
>>>>> Bonjour,
>>>>>
>>>>> Le 10/03/2019 à 17:49, Florimond Berthoux a écrit :
>>>>> > Bonjour,
>>>>> >
>>>>> > Utiliser un point et non un polygone, à placer à peu près au centre de
>>>>> > la région (en espérant qu'il n'y ai pas une guerre de religion du vrai
>>>>> > centre :) ?
>>>>> > C'est ce qui est fait pour les quartiers de Paris, par exemple la Goutte
>>>>> > D'or https://www.openstreetmap.org/node/2142414234
>>>>>
>>>>> Les quartiers de Paris ne sont pas un bon exemple ici, car contrairement
>>>>> aux régions vécues, dont chacun a sa propre limite (Marc_marc parle de
>>>>> subjectivité et c'est bien le problème de ces limites), les 80 quartiers
>>>>> de Paris ont une définition précise pour leurs limites, reprise par 80
>>>>> relations comme celle-ci :
>>>>> https://www.openstreetmap.org/relation/2195145#map=15/48.8927/2.3547
>>>>>
>>>>> Pour revenir à la question initiale pas sûr que boundary=historic soit
&g

Re: [OSM-talk-fr] Les contours de la Bretagne

[althio]

Bonjour Frederik,
(english version below)
Jean-Yvon, @talk-fr,

Ces éditions ont l'air d'être
- nuisible : ne reflètent pas la situation administrative réelle, mais
un point de vue alternatif ou historique
- presque inutile : seules les attributs sur les ways sont affectés,
pas les relations (donc pas d'impact significatif sur la plupart des
utilisateurs de données et des moteurs de rendu)
- pas selon la convention de OSM : les noms sont ajoutés sur les ways
- massif : beaucoup d'éléments sont modifiés
- de mauvaise foi : nouveau compte, pas de discussion, 

De plus, d'autres erreurs ont été introduites (par erreur, pas
intentionnellement), au moins :
https://www.openstreetmap.org/way/70292141
Cette voie est à la fois "boundary=administrative" (avec les attributs
supplémentaires) et "waterway=river" (avec les attributs
supplémentaires).
Mauvaise modification : changement du nom (le nom introduit est lié à
la limite administrative mais s'applique à la rivière).
Résultat : cette (petite) portion du fleuve à Redon s'appelle
désormais "Loire-Atlantique" au lieu de "La Vilaine" (et cela apparaît
sur la carte OSM Standard).

Peut-être que les gens autour de Nantes pourraient y jeter un coup
d’œil de plus près.
Pour l'instant, je ne pense pas que ces éditions introduisent quoi que
ce soit de bon ou d'utile.
Je suis d'accord que cela devrait être annulé (full revert), si c'est
encore possible 2 mois après...

---
english version
---

These edits looks
- harmful: not reflecting the actual administrative situation, but an
alternative or historic point of view
- almost useless: only tags on ways are affected, not the relations
(hence no significant impact on most data users and renderers)
- not per OSM convention: names are added to boundary ways
- heavy: a lot of ways are changed
- in bad faith: new account, no discussion, ...

Additionally, errors were introduced (by mistake, not on purpose), at
least this:
https://www.openstreetmap.org/way/70292141
This way is both "boundary=administrative" (with additional related
tags) and "waterway=river" (with additional related tags).
Bad edit: changed the name (name introduced is related to the boundary
but is applied to the waterway)
Result: this (small) portion of the river in Redon is now named
"Loire-Atlantique" instead of correct "La Vilaine" (and this shows on
OSM Standard map).

Maybe people around Nantes can have a closer look.
At the moment I don't think anything else good or useful is introduced
by these edits.
I agree they should be reverted in full, if this is still possible 2
months later.

On Fri, 8 Mar 2019 at 22:18,  wrote:
>
> (Summary below)
>
> J'ai regardé quelques points, ça ne m'a pas l'air d'être complètement le cas.
>
> Par exemple 
> https://www.openstreetmap.org/way/656836115/history#map=9/47.6339/-1.1838
>
> passe de 8/commune (faux) à 6/departement (faux, hélas ;-)).
>
> Ça devrait être 4/region.
>
> https://www.openstreetmap.org/way/35792233/history
>
> Là ça semble bien être le cas.
>
> Discussion sur les changeset ou revert?
>
> Comme je suis pour le retour de la Loire-Atlantique en Bretagne, je veux bien 
> faire un commentaire (ou un texte expliquant le blocage de l'utilisateur).
>
> Ceci dit cet utilisateur a fait exactement deux modifications, or on ne fait 
> pas des milliers de modification dans ses deux premières éditions.
>
> Donc plutôt pour un revert et un blocage de l'utilisateur car il s'agit à mon 
> avis de mauvaise foi.
>
> On devrait comme Wikipédia avoir deux entrées, dont une relation Bretagne 
> historique / (alt_name Bretagne) définie par les 5 départements bretons en 
> subarea. Et en mettant en end_date la création par Pétain de la Bretagne 
> amputée (ou 1972 lors de la recréation des région par De Gaule/Debré).
>
> Au fait quelqu'un sait l'utilité de la relation Bretagne sans îles ni 
> capitale ?
>
> Frederik tut mir leid für die Sprache aber falls du es weiterleiten willst...
>
> Summary: this user made exactly 2 edits, modifying thousands of objects in 
> those two edits. So it's a fake user, I'm for 2 actions: revert + user block 
> as he/she created the user by purpose.
>
> We should add a new relation "Brittany" using the 5 départements as subarea 
> (for easier maintenance) but having an end_date.
>
> I can imagine to write the text the user would read when being blocked (as 
> I'm also for a full-size Brittany)
>
> Jean-Yvon
>
> Le 08/03/2019 à 21:18, Frederik Ramm - frede...@remote.org a écrit :
>
> Bonjour talk-fr,
>
> someone has reported these two changesets
>
> https://www.openstreetmap.org/changeset/66342909
> https://www.openstreetmap.org/changeset/66285978
>
> and said:
>
> "Cet utilisateur a rédifini les contours de la Bretagne incluant le
> département de la Loire Atlantique. Si ce sujet est bien débattu, et n'a
> actuellement aucun impact sur le tracé des contours administratifs
> régionaux. OpenStreetMap n'a pas à recevoir des données qui proviennent
> d'un choix personnel et qui ne sont pas une 

Re: [OSM-talk-fr] attributs pour service d'aide à la personne

[althio]

Bonjour,

ça va commencer par :
office <https://wiki.openstreetmap.org/wiki/FR:Key:office>=*

https://wiki.openstreetmap.org/wiki/FR:Key:office
> Un endroit (bureau(x)) offrant principalement des services commerciaux

... ensuite...

> Comme la liste des valeurs est potentiellement très grande, vous êtes
libre de créer la vôtre

... c'est freestyle <https://taginfo.openstreetmap.org/keys/office#values>-
tagging <https://taginfo.openstreetmap.org/keys/company#values>, alors
pourquoi pas :

office=cleaning;childcare;gardening;home_care;handyman

et puis j'invente encore :
home_care:for=senior;disabled

-- althio


On Tue, 5 Mar 2019 at 11:59, Julien Lepiller  wrote:

> Bonjour !
>
> quel serait la bonne combinaison d'attributs pour une société de
> services d'aide à la personne (en l'occurrence, « ménage, nounou,
> jardin, seniors, handicaps, info, brico ») ?
>
> Merci !
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Taguer une fourrière ?

[althio]

Rien trouvé dans le wiki, et seulement quelques usages dans la base, pas
encore significatif :

https://taginfo.openstreetmap.org/tags/amenity=vehicle_impound
https://taginfo.openstreetmap.org/tags/amenity=tow_pound
https://taginfo.openstreetmap.org/tags/amenity=car_pound

Ou parfois une combinaison de tags existants, du genre :
amenity=parking
access=private
landuse=industrial
name=... Car Pound

-- althio


On Sat, Mar 2, 2019, 13:58 Cédric Frayssinet  wrote:

> Bonjour à tous,
>
> Savez-vous comment taguer une fourrière pour voitures, je n'ai pas trouvé
> d'infos sur le wiki ?
>
> Merci !
>
> Cédric
>
>
> --
> Dégooglisé ! <https://degooglisons-internet.org/> - Sociétaire Enercoop
> <https://souscription.enercoop.fr/code/PARRAIN_OrcGUb>, l'énergie
> militante
>
> Sur Mastodon : @bristow...@framapiaf.org
> <https://framapiaf.org/@Bristow_69>
>
> [image: Promouvoir et soutenir le logiciel libre] <http://www.april.org>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

On Sat, Mar 2, 2019, 13:58 Cédric Frayssinet  wrote:

> Bonjour à tous,
>
> Savez-vous comment taguer une fourrière pour voitures, je n'ai pas trouvé
> d'infos sur le wiki ?
>
> Merci !
>
> Cédric
>
>
> --
> Dégooglisé ! <https://degooglisons-internet.org/> - Sociétaire Enercoop
> <https://souscription.enercoop.fr/code/PARRAIN_OrcGUb>, l'énergie
> militante
>
> Sur Mastodon : @bristow...@framapiaf.org
> <https://framapiaf.org/@Bristow_69>
>
> [image: Promouvoir et soutenir le logiciel libre] <http://www.april.org>
> ___
> 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] traduction jughandle

[althio]

> faire une description style "carrefour où le tourner à gauche
et/ou à droite sont interdit au point de croisement lui-même et se font
via une bretelle"

Oui, d'accord avec toi :)

> plutôt que d'inventer un terme qui n'existe pas,
il me semble préférable de garder le terme jughandle

Non, pas d'accord avec toi :)

- jughandle est un terme qui n'existe pas, en français
- même en anglais, c'est plutôt abscons, et il a bien fallu l'inventer un
jour ou l'autre "jughandle"
- un terme même approximatif en français sera toujours mieux
- tourne-à-gauche, tourne-à-gauche indirect sont des termes existants (tu
peux les retrouver dans les liens que j'ai indiqué)
- je ne vois pas un grand niveau d'inventivité à utiliser des termes
descriptifs comme "bretelle en tourne-à-gauche" ou "bretelle et
tourne-à-gauche" ou "bretelle de carrefour"

> il en existe qui sont aussi des tourner à gauche et droite.

C'est le tourne-à-gauche qui en fait quelque chose de spécial.
Une bretelle qui finit en tourne-à-droite, ça n'a pas la forme d'une anse
et pas le nom "jughandle".

-- althio


On Thu, 21 Feb 2019 at 20:09, marc marc  wrote:

> il en existe qui sont aussi des tourner à gauche et droite.
> plutôt que d'inventer un terme qui n'existe pas,
> il me semble préférable de garder le terme jughandle
> et de faire une description style "carrefour où le tourner à gauche
> et/ou à droite sont interdit au point de croisement lui-même et se font
> via une bretelle"
>
> Le 21.02.19 à 18:07, althio a écrit :
> > Je suis bien d'accord que la dénomination "bretelle" est un peu bâtarde,
> > mais que "bretelle de croisement" ou même "bretelle de carrefour"
> > pourrait convenir.
> >
> > Il y a aussi effectivement "tourne-à-gauche" mais qui, employé seul,
> > fait plutôt référence à une simple voie de type qui se décale
> > directement sur la gauche sans "jughandle"
> >
> https://fr.wikipedia.org/wiki/Voie_de_circulation_(route)#Voie_de_tourne-%C3%A0-gauche
> >
> > Mais quand même, notre "jughandle", on dirait bien un "tourne-à-gauche"
> > au bout d'une "bretelle".
> >
> > J'ai envie de proposer "bretelle tourne-à-gauche", mais je ne sais pas
> > si cela évoque la bonne configuration pour vous ?
> > Sinon j'ai vu passé un "tourne-à-gauche indirect"...
> >
> > -- althio
> >
> > Mes 2 cents après quelques recherches sur :
> > https://fr.wikipedia.org/wiki/Bretelle_(transport)
> >
> https://fr.wikipedia.org/wiki/Voie_de_circulation_(route)#Voie_de_tourne-%C3%A0-gauche
> >
> https://www.letelegramme.fr/morbihan/vannes/rn165-fermeture-du-tourne-a-gauche-du-liziec-a-vannes-30-06-2017-11578984.php
> >
> https://ville-nogentsurmarne.com/pont-de-nogent-avancement-des-travaux-2/
> > http://www.ville-saran.fr/reouverture-de-la-bretelle-de-la-chiperie
> >
> https://ffvelo.fr/wp-content/uploads/2013/10/Pages-de-CHARTE-CYCLABLES-2016-9.pdf
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] traduction jughandle

[althio]

Je suis bien d'accord que la dénomination "bretelle" est un peu bâtarde,
mais que "bretelle de croisement" ou même "bretelle de carrefour" pourrait
convenir.

Il y a aussi effectivement "tourne-à-gauche" mais qui, employé seul, fait
plutôt référence à une simple voie de type qui se décale directement sur la
gauche sans "jughandle"
https://fr.wikipedia.org/wiki/Voie_de_circulation_(route)#Voie_de_tourne-%C3%A0-gauche

Mais quand même, notre "jughandle", on dirait bien un "tourne-à-gauche" au
bout d'une "bretelle".

J'ai envie de proposer "bretelle tourne-à-gauche", mais je ne sais pas si
cela évoque la bonne configuration pour vous ?
Sinon j'ai vu passé un "tourne-à-gauche indirect"...

-- althio

Mes 2 cents après quelques recherches sur :
https://fr.wikipedia.org/wiki/Bretelle_(transport)
https://fr.wikipedia.org/wiki/Voie_de_circulation_(route)#Voie_de_tourne-%C3%A0-gauche
https://www.letelegramme.fr/morbihan/vannes/rn165-fermeture-du-tourne-a-gauche-du-liziec-a-vannes-30-06-2017-11578984.php
https://ville-nogentsurmarne.com/pont-de-nogent-avancement-des-travaux-2/
http://www.ville-saran.fr/reouverture-de-la-bretelle-de-la-chiperie
https://ffvelo.fr/wp-content/uploads/2013/10/Pages-de-CHARTE-CYCLABLES-2016-9.pdf


On Wed, 20 Feb 2019 at 17:05, Vincent de Château-Thierry 
wrote:

> Bonjour,
>
> > De: "marc marc" 
> >
> > peux-être que cela ne se traduit pas en français tout simplement
> > vu leur faible existence en francophonie.
>
> 2 cas parmi sûrement beaucoup d'autres en région parisienne :
> https://www.openstreetmap.org/way/82987762
> https://www.openstreetmap.org/way/279301002
>
> > Le 20.02.19 à 16:10, Julien Lepiller a écrit :
> > > J'ai bien compris comment ça fonctionnait (j'ai lu l'article
> > > wikipédia), ma question est de savoir comment traduire ça. On
> > > pourrait remettre en question le choix d'iD d'utiliser ça, ou
> > > l'intérêt de cet attribut, mais ce n'était pas le sens de ce
> > > thread :)
> > >
> > > Par contre, passage à niveau, c'est pas plutôt pour les trains ?
> > > En tout cas c'est déjà utilisé pour autre chose, alors je préfère
> > > éviter la confusion…
> > >
> > > Le 2019-02-20 14:59, osm.sanspourr...@spamgourmet.com a écrit :
> > >> Passage à niveau ;-).
>
> Croisement à niveau me paraît moins connoté "réseau ferré". Bretelle
> évoque l'absence de croisement à niveau habituellement donc parler de
> "bretelle de croisement" serait un peu bâtard. Mais en même temps ce sont
> bien les deux idées qui sont réunies dans ce type de configuration.
>
> À suivre
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Recherche astuce overpass

[althio]

Une piste avec ça ? Mais y'a certainement d'autres méthodes, aucune idée si
c'est optimisé.
http://overpass-turbo.eu/s/G8C

>
relation["boundary"="administrative"]["admin_level"="8"](area.searchArea)->.members;
> way(r.members);

cf. doc
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Recurse_.28n.2C_w.2C_r.2C_bn.2C_bw.2C_br.29

On Fri, 15 Feb 2019 at 01:04, Nicolas Moyroud  wrote:

> Bonjour à tous,
>
> J'en appelle ici aux grands manitous d'overpass pour un petit souci qui
> m'ennuie un peu avec certaines requêtes. Il m'arrive de temps en temps
> d'extraire des limites administratives avec overpass. Par exemple avec
> cette requête : http://overpass-turbo.eu/s/G8k
>
> Ça marche mais il y a un petit détail qui m'ennuie. Ce sont seulement
> les limites administratives qui m'intéressent, or dans les données
> renvoyées il y a également les points des chefs-lieux de chaque commune.
> Ce que je fais c'est que j'ouvre le fichier avec QGIS et je ne sauve que
> les polygones dans un fichier geojson. Donc je m'en sors comme ça, mais
> je me dis qu'à tous les coups il y a moyen de dégager les points
> directement avec overpass et donc de gagner une manip en moins avec
> QGIS. Une idée ?
>
> Nicolas
>
>
> ___
> 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] Moulinette pour ajouter "oneway:bicycle=no" ?

[althio]

Peut-être que dans ce cas l'outil devrait s'adapter aux données, et pas
l'inverse ?

Il semble que BRouter prend en compte oneway:bicycle depuis 2017 ...
https://github.com/abrensch/brouter/issues/51

... et cycleway=opposite|opposite_lane|opposite_track par la même occasion :
> if ( cycleway=opposite|opposite_lane|opposite_track ) then 0
> else if ( oneway:bicycle=no ) then 0

... et bientôt peut-être le même traitement pour cycleway:left=opposite*
et cycleway:right=opposite*
https://github.com/abrensch/brouter/pull/123


On Fri, 1 Feb 2019 at 14:47, Gwenaël Jouvin via Talk-fr <
talk-fr@openstreetmap.org> wrote:

> Bonjour,
>
> En effet Thomas, il y a probablement, à l’origine, une histoire de
> compatibilité et de doublon.
>
> Une page du Wiki décrivait très bien le problème, mais elle a été modifiée
> depuis [1]. Voici le texte qui me servait de référence à l’époque :
> « Oneway can be used in conjunction with vehicle type in order to tag
> exceptions. I.e. oneway:moped=no for a one-way streets where mopeds are
> allowed to drive in the opposite direction. Bicycles (oneway:bicycle=no)
> are handled specially and  cycleway=opposite/opposite_lane/opposite_track
> needs to be added for compatibility: (See Key:access for sub-values or
> Bicycle for examples). »
>
> Pour ma part, j’avais découvert la « nécessité » de cycleway=opposite car
> le rendu OCM n’affichait pas les double-sens cyclables qui n’avaient pas
> cet attribut.
>
>
> Gwenaël
>
> [1]
> https://wiki.openstreetmap.org/w/index.php?title=Key:oneway=1576104=1576102
>
>
> Le 01/02/2019 à 13:47, Thomas Ruchin a écrit :
> > Je pense que c'est du doublon d'information qui n'apporte pas grand
> chose et qui est difficile à maintenir. Je ne sais pas quelle est la
> discussion qui a conduit à cette rédaction du wiki.
> > C'est comme si le wiki recommandait d'ajouter access=yes sur les routes
> qui n'ont pas de restriction particulières d'accès.*
> > Par contre, rechercher à mieux caractériser les voies sur lequel est
> présent le oneway:bicycle=non sans plus de détail sur l'aménagement
> cyclable serait intéressant.
> >
> > Thomas
>
> ___
> 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] Cimetière militaire

[althio]

Une idée, ce serait :
cemetary = military
mais ça n'existe pas encore.

Il y a une tentative polonaise de :
cemetery:usage = war/military/family
mais c'est confidentiel.

Pourquoi non plus :
cemetary = sector
sector = military
(ou cemetary:sector = military)

On Thu, 24 Jan 2019 at 17:49, Florian LAINEZ  wrote:

> Hello,
> J'aimerai indiquer un carré militaire dans un cimetière :
> https://www.openstreetmap.org/way/665897392
>
> Pour l'instant je l'ai taggué landuse=military mais je n'en suis pas très
> fier :P
> Je cherche le tag adéquat et n'ai pas trouvé.
>
> JOSM propose un preset "cimetière militaire" et rajoute dans ce cas :
> historic=tomb
> tomb=war_grave
> Il arrive que ces tags soient appliqués à des cimetières, comme par
> exemple https://www.openstreetmap.org/way/24893223
> Or d'après moi ces tags désignent une tombe et non pas un cimetière / une
> division de cimetière.
>
> Une idée ?
>
> --
>
> *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] Origine des données Waze

[althio]

En France, je dirais qu'il est problable qu'une bonne partie du socle de
données de Waze (ou Google Maps) provient des bases gratuites ou payantes
de l'IGN.

-- althio

On Sun, 20 Jan 2019 at 22:14, deuzeffe  wrote:

> Bonsoir,
>
> À la suite de l'article de Numérama
> (
> https://www.numerama.com/tech/455697-on-a-mis-un-feu-rouge-improbable-a-lentree-de-la-ville-les-astuces-du-maire-de-lieusaint-pour-tromper-waze.html
> ), j'ai tenté de satisfaire ma curiosité en allant voir ce que
> représentait et mettait en avant une carte Waze, dans ma zone de confort
> (celle que je connais le moins mal, donc).
>
> Et j'ai été très surprise d'y trouver des objets que j'ai récemment ou
> pas (plus ou moins mal) mapés comme des parkings, des chemins piétons,
> des landuse de forme bizarre, etc., bref des trucs pour lesquels, sans
> verser dans la paranoïa ou le complexe de supériorité, j'ai l'intime
> conviction qu'ils proviennent d'osm (ou de quelqu'un qui waze dans mon
> coin en étant très précis - et ce n'est pas moi ^^).
>
> D'où ma question, à part les wazeurs et wazeuses (pas comme mes
> blagues), quelle est l'origine des données Waze (Tous droits réservées
> Waze Mobile, dit le cartouche en bas de carte) ?
>
> (ce ne sont pas les cartes publiques de GG maps : elles sont encore plus
> fausses).
>
> Une idée ?
> --
> deuzeffe, soupçonneuse.
>
>
> ___
> 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] La carte Près de Chez Nous PDCN

[althio]

On Sat, 12 Jan 2019 at 11:57, marc marc  wrote:
>
> Le 12.01.19 à 11:53, osm.sanspourr...@spamgourmet.com a écrit :
> >> en coopératives ou pas
>
> > on doit bien pouvoir leur trouver une clé
>
> operator:type=ngo ?

operator:type=cooperative
sur https://wiki.openstreetmap.org/wiki/Key:operator:type
(à rajouter sur la version française)

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

Re: [OSM-talk-fr] Mise à jour du rendu "hydro"

[althio]

Outre le bleu et le mauve, je vois aussi des ponctuels orange,
typiquement des châteaux d'eau, réservoirs, stations de traitement ou
pompage...

Au passage, les libellés sont parfois abrégés (en fonction du zoom),
parfois comportent des erreurs du genre encodage de caractères.

ex : RÄ©servoir ; Réserv. ; ChÄ¢teau d'eau ; Ch. Eau

--
Benoît

On Sat, 12 Jan 2019 at 09:19, Christian Quest  wrote:
>
> Dans la couche hydro de la BD Topo, il y a une table reservoir_eau et une 
> table point_eau
>
> Quasiment aucune info à part la nature de l'objet et un id: réservoir 
> (45526), chateau d'eau (11798) , source (48798), source captée (13381), 
> fontaine (29063), station de pompage (19259), citerne (6803) et autre (31056)
>
> Au total il y a pas loin de 200.000 objets.
>
> Dans la BD Carthage (plus ancienne), il y a plus d'infos: toponyme, cote
> - reservoirs: 36126
> - château d'eau: 12028
> - station de pompage: 11006
> - station de traitement: 8944
>
> Bref... jette un oeil sur les docs et les données ;)
>
>
>
> Le ven. 11 janv. 2019 à 21:10, François Lacombe  a 
> écrit :
>>
>> Merci Christian, ce rendu est super utile.
>>
>> Comme je vois les réservoirs visibles sur la carte, il faudrait que je fasse 
>> des demandes d'opendata à tous les services de l'eau pour avoir plus d'infos.
>> Est-ce que c'est facile de faire une extraction de ces points depuis la BD 
>> Carthage ?
>> Quels sont les attributs disponibles ?
>>
>> Bonne soirée
>>
>> François
>>
>> Le jeu. 10 janv. 2019 à 09:29, Christian Quest  a 
>> écrit :
>>>
>>> J'ai mis à jour hier soir les données de la couche "Hydro" qui combinent la 
>>> BD Carthage (un peu ancienne maintenant) et la couche hydro de la BD Topo 
>>> (en licence ouverte depuis déjà quelque temps).
>>>
>>> Infos ici: 
>>> https://wiki.openstreetmap.org/wiki/FR:Serveurs/tile.openstreetmap.fr#Hydro
>>>
>>> Vue directe: 
>>> https://tile.openstreetmap.fr/?zoom=16=48.81578=2.40922=00B00FT
>>>
>>> En bleu: source BD Carthage
>>> En Mauve: source BD Topo Hydro (octobre 2018)
>>>
>>> --
>>> 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
>
>
>
> --
> 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] Source = livre sous copyright

[althio]

Bonjour,

Je ne suis pas juriste non plus :) et voici ce que j'ai compris :

La carte, le style cartographique, la représentation des données :
- expression de la créativité de l'auteur : oui
- le droit d'auteur s'applique : oui
- license typique dans l'écosystème OSM : CC-BY-SA, mais libre de choix par
l'auteur
- texte copyright OSM : "Nos carreaux de rendu cartographiques, ainsi que
notre documentation, sont disponibles sous la licence Creative Commons
paternité – partage à l’identique 2.0
<https://creativecommons.org/licenses/by-sa/2.0/> (CC-BY-SA)." version
originale : "The cartography in our map tiles, and our documentation, are
licensed under the Creative Commons Attribution-ShareAlike 2.0
<https://creativecommons.org/licenses/by-sa/2.0/> license (CC BY-SA)."
- Le droit de citation s'applique : peut-être, il faut voir, c'est une
notion particulière selon les pays, la license utilisée n'est pas
française. Cela revient à dire qu'on pourrait copier un extrait (image) de
carte ou un extrait (texte) de documentation sans se soucier de license.
- et hors d'OSM ? Copier un style de carte (Michelin, IGN, ...), c'est
tendu... Copier un bout d'image de carte priopriétaire (avec citation mais
sans permission), à voir si l'utilisation a réellement valeur de simple
citation... Copier des données représentées dans la carte, on sort du
cadre...


Les données :
- expression de la créativité de l'auteur : non
- le droit d'auteur s'applique : non
- le droit des bases de données s'applique : oui
- license dans l'écosystème OSM : ODbL (depuis 2012)
- texte copyright OSM : "OpenStreetMap®
<https://www.openstreetmap.org/copyright#trademarks> est un ensemble
de *données
ouvertes*, disponibles sous licence libre Open Data Commons Open Database
License <https://opendatacommons.org/licenses/odbl/>(ODbL) auprès de
la Fondation
OpenStreetMap <https://osmfoundation.org/> (OSMF)." version originale : "
OpenStreetMap® <https://www.openstreetmap.org/copyright/en#trademarks> is *open
data*, licensed under the Open Data Commons Open Database License
<https://opendatacommons.org/licenses/odbl/> (ODbL) by the OpenStreetMap
Foundation <https://osmfoundation.org/> (OSMF)."
- Le droit de citation s'applique : Non, et surtout pas pour recopier dans
une autre base de données.
(C'est pas du droit, mais vous imaginez 1000 contributeurs qui font
recopient 1 élément par jour pendant 1 an ?)

Combinaison des deux éléments (droits sur la carte et droits sur les
données) :
exemples de mentions complètes :
- Map data © OpenStreetMap contributors, tiles GIScience Research Group @
Heidelberg University
- Tiles courtesy of jawgmaps - Map data © OpenStreetMap contributors, under
ODbL
- Map tiles by Stamen Design, under CC BY 3.0. Data by OpenStreetMap, under
ODbL
- Map tiles by CartoDB, under CC BY 3.0. map data © OpenStreetMap
contributors under ODbL
- Maps © Thunderforest, Data © OpenStreetMap contributors
- map data © OpenStreetMap - Tiles courtesy of Lyrk

Il y a des zones grises dans l'interprétation des licenses.
Mais le droit de citation sur des données pour les copier dans une autre
base de données me semble clairement dans la zone noire. C'est donc clair :
Pas de données sous copyright pour mettre dans OSM (même pas un petit peu,
juste là, juste une fois, pour N contributeurs).
Et pour les pratiques un peu dans la zone grise, la position du projet OSM
règle le problème (technique du plus blanc que blanc) : si il y a un doute,
on ne prend pas. On a déjà assez de sources avec les contributions
personnelles originales et les données ouvertes et les données partagées.

-- althio


On Sat, 15 Dec 2018 at 10:56, Leo Gaspard  wrote:

> (deuxième tentative après l'utilisation de la mauvaise adresse mail
> source pour le premier envoi)
>
> Rpnpif  writes:
> > Mais le droit de citation existe quand même quand le texte est
> > suffisamment court. Non ?
>
> Plus intéressant que le droit de citation… le droit d'auteur ne
> s'applique en fait pas aux cartes sous la législation française, comme
> le montre [1] en indiquant « Pour être protégées, ces créations doivent
> être originales (expression juridique de la créativité de l'auteur)
> et [...] ».
>
> [1]
> https://www.service-public.fr/professionnels-entreprises/vosdroits/F23431
>
> À moins qu'il n'y ait expression de la créativité de l'auteur dans
> l'emplacement des points sur une carte du monde réel, le droit d'auteur
> ne s'applique pas aux données qu'on pourrait vouloir reproduire dans
> OSM.
>
> Après, je ne suis pas juriste. Mais il me semble que la position d'OSM
> est une position qui n'est pas supportée par une base légale, au moins
> en France. Ce qui ne l'empêche pas d'être la position du projet.
>
> ___
> 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] représentation 3d des olympiades

[althio]

La dalle en tant que voirie, aire de cheminement existe déjà :
https://www.openstreetmap.org/relation/3283058

Ce way https://www.openstreetmap.org/way/79084943 :
C'est peut-être plutôt le bâtiment sous la dalle.
(donc peut-être remettre building=yes ? le bon nombre d'étages ? 2 ?
enlever le tag "name" ?... ???)


On Mon, 15 Oct 2018 at 20:31, Nicolas Bétheuil  wrote:

> Du coup j'ai plutôt utilisé area=yes & pedestrian=yes et j'ai enlevé le
> fait que c'était un immeuble
> https://www.openstreetmap.org/changeset/63551936
>
>
> Le lun. 15 oct. 2018 à 18:15, Philippe Verdy  a
> écrit :
>
>> N'est-ce pas le même problème sur d'autres "dalles" comme celle de la
>> Défense à Courbevoie, ou la dalle du Colombier à Rennes ? Et le même
>> problème dans toutes les villes construites sur des reliefs escarpés (comme
>> Monaco), où il est difficile de dire quel est le niveau du "sol" pour un
>> étage donné qui peut être sous-terrain ou en hauteur d'un autre côté avec
>> d'autres niveaux intercalaires?
>>
>> La notion de "niveau" (ou "étage") se gère à priori bâtiment par
>> bâtiment, pourtant on trouve des cas où deux batiments contruits sur des
>> sols différents ont des passages accolés au même niveau (on passe san
>> monter ou descendre du rez-de chaussée de l'un au 3e étage de l'autre) et
>> on en trouve même dans des villes réputées "plates" comme Paris (les
>> "grands magasins") ou Lille (par exemple sa fameuse grande librairie) qui
>> ont aussi réunit des niveaux différents de plusieurs bâtiments accolés (ou
>> assez proches pour installer des passerelles).
>>
>> Dans certains cas, au sein de ces batiments, la notion de "niveau" n'est
>> pas la même entre les surfaces occupées par un même magasin ou une même
>> entreprise, que celle d'étage au sein des batiments dans lesquels ces
>> locaux sont situés.
>>
>> On a le cas aussi avec les stations souterraines de train ou métro, où la
>> notion de niveau n'est pas beaucoup plus simple (le même niveau peut
>> pourtant avoir des altitudes de plancher variables, avec des pentes douces
>> ou quelques marches ignorées et sur une longueur assez grande cela fait
>> vite une différence).
>>
>> Le tag "layer=n" d'OSM ne donne qu'une relation d'ordre relatif entre des
>> éléments superposés à la même position géographique (longitude et
>> latitude), le tag "level=n" dans un batiment peut ne pas suffire non plus,
>> et il est difficile de taguer précisément tous les points avec une
>> véritable altitude, à moins de décider de ne plus taguer ça dans OSM
>>
>> Mais on peut le faire avec un véritable modèle 3D (hors d'OSM lui-même)
>> pour l'ensemble d'un édifice, qu'on géolocalisera ensuite sur un seul point
>> (avec aussi son orientation correcte) ; et alors dans OMS on se contentera
>> de tracer la seule empreinte au sol, quel que soit son altitude. Mais il
>> manquera alors dans OSM les "ways" de communication (on mes ajoute de façon
>> approximative sans tenir compte de l'altitude, mais en les ordonnant avec
>> "layer=n", le reste est trop difficile à modéliser avec le modèle 2D d'OSM
>> qui n'est pas conçu pour gérer correctement la 3e dimension).
>>
>>
>>
>> Le lun. 15 oct. 2018 à 17:40, Nicolas Bétheuil  a
>> écrit :
>>
>>> Tout le monde se sera bien entendu rendu compte qu'il n'y a pas de 3d
>>> dans mapcontrib mais plutôt streetcomplete.
>>>
>>> My bad, Désolé pardon plates excuses confusantes.
>>>
>>> Le lun. 15 oct. 2018 13:58, Nicolas Bétheuil  a
>>> écrit :
>>>
 Bonjour,

 En me baladant hier, je suis passé dans le 13ème à faire un peu de
 MapContrib
 Le rendu 3d est vraiment pas terrible
 https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30

 Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle
 faisait 20 étages et du coup les commerces présents sur la dalle sont juste
 invisible.

 Vous auriez une idée de comment améliorer ça ?

>>> ___
>>> 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] Coopérative de transformation de fruits en jus de fruits

[althio]

J'aurai tapé du côté de de ces tags :
(pour un lieu de transformation)
man_made=works
product=juice

On Mon, 8 Oct 2018 at 11:43, Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> Bonjour,
>
> https://wiki.openstreetmap.org/wiki/Key:craft me semble tout à fait
> pertinent.
>
> craft=juicery ?
>
>
> Le lun. 8 oct. 2018 à 11:15, Nicolas Moyroud  a écrit :
>
>> Bonjour à tous,
>>
>> Je cherche à ajouter dans OSM un SCIC (société coopérative d'intérêt
>> collectif) qui est un atelier artisanal de transformation de fruits en
>> jus de fruits. Le principe est que chacun peut amener ses fruits (à
>> partir de 100kg) et repartir avec son jus pressé par la coopérative.
>> Pour les curieux, plus de détails ici : https://www.nectardechois.fr/
>>
>> Le souci c'est qu'il ne s'agit ni d'un lieu de production, ni d'un lieu
>> de vente. Du coup j'ai beau chercher sur le wiki je ne trouve pas
>> d'indication sur la manière appropriée de tagguer ça. Donc si il y en a
>> parmi vous qui ont une idée, je suis preneur !
>>
>> Nicolas
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Florimond Berthoux
> ___
> 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] [OSM-Talk-fr] Opening_hours au changement d'heure

[althio]

réponse ici :
https://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Daylight_Savings

le dernier dimanche de mars et le dernier dimanche d'Octobre, c'est avec un
truc du genre :
Mar Su[-1]-Oct Su[-1]


On Tue, 25 Sep 2018 at 11:26, Florian LAINEZ  wrote:

> Hey, je n'ai pas trouvé comment indiquer un changement d'horaire
> d'ouverture lors du changement d'heure été/hiver cf. photo
> 
> En attendant une éventuelle réforme, pour l'instant le changement d'heure
> a en effet lieu a des dates différentes chaque année : le dernier
> dimanche de mars à 2h et le dernier dimanche d'Octobre à 3h
> .
> Le wiki  ne parait
> pas prendre en compte cette possibilité, help !
>
> --
>
> *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] cartographie d'un institut de formation

[althio]

En première lecture, mes impressions sont :

> J'aime bien le amenity=training
<https://wiki.openstreetmap.org/wiki/Proposed_features/training> ou
amenity=training_center
<https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dtraining_center>
mais
ils sont restés en "proposed feature",
auquel on pourrait ajouter "training:FR=BAFA".

+1 : pourquoi pas, bonne piste

> J'ai l'impression que le plus proche (la bonne réponse ;-) ) soit
amenity=college
<https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dcollege> "*Établissement
d'enseignement supérieur (post-bac) non universitaire (école, grande
école...)*" avec peut-être college:FR=BAFA ;-)

-1 : le BAFA n'est pas de l'*enseignement supérieur (post-bac)*

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

[OSM-talk-fr] State of The Map 2018 - Milan

[althio]

Bonsoir,

Suite à la conférence internationale SotM 2018, je vous invite à lire
cet article détaillé, écrit par Paul Desgranges et complété
collaborativement par d'autres membres de la communauté française et
de l'association OpenStreetMap France.

http://next.openstreetmap.fr/state-of-the-map-2018-a-milan/

Bonne lecture.
Si vous cherchez d'autres lectures dans d'autres langues, surveillez ici :
https://www.openstreetmap.org/diary
et là :
http://www.weeklyosm.eu/fr/archives/10586

-- althio -- Benoît

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

Re: [OSM-talk-fr] Lieux d'accueil enfants-parents

[althio]

Je me lance, je tente des pistes :

amenity=childcare
childcare:FR=accueil_enfants_parents
social_facility:for=parents
min_age=*
max_age=6
supervised=yes
… ?

-- althio




On Thu, Aug 9, 2018, 23:55 deuzeffe  wrote:

> Bonsoir,
>
> Les LAEP (ou parfois LAPE) sont des structures (~ 1500 ) officiellement
> reconnues et soutenues par la CAF (cf
>
> http://www.caf.fr/allocataires/vies-de-famille/futur-parent/garde-d-enfant/les-lieux-d-accueil-enfants-parents
> ; il y a même une base en LO/OL),
>
> C'est donc dans le thème enfance. Mais quel(s) tag(s) ? Ce ne sont pas
> des kinderkarten, même si ça peut s'en rapprocher. Quel tag pourrait-on
> utiliser voire créer ?
>
> Merci pour vos réponses, quelles qu'elles soient.
> --
> deuzeffe
>
> ___
> 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] Présentation rapide

[althio]

2018-07-23 14:33 GMT+02:00  :

> [...] sur l'accessibilité des lieux
>
> Par exemple, ce trottoir est-il particable ? Plein de trous ? En pente ?
> Pavé (les pavés sont une calamité en fauteuil roulant) ? etc.
>
> Je pense qu'il faut discuter des tags possible.

Beaucoup de choses existent dans les tags, et bien répertoriées par la
page proposée auparavant
https://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel

{praticable} : wheelchair=yes | no | bad
{plein de trous} : smoothness=* ;
https://wiki.openstreetmap.org/wiki/FR:Key:smoothness
{en pente} : incline=* ; https://wiki.openstreetmap.org/wiki/FR:Key:incline
{pavé} : surface=sett | cobblestone | * ;
https://wiki.openstreetmap.org/wiki/FR:Key:surface


> J'en reviens aux auto-école. Il existe une liste de code qui sont
> associés à des aménagements. Il va de sois que ces aménagements, s'ils
> sont quasiment les mêmes dans tous les pays « occidentaux »[1] les codes
> eux diffères. Du coup faut-il une liste de tags avec true/false, ou un
> autre moyen (que ne je connais pas forcément).

On peut envisager une liste de tags en yes/no en s'inspirant de
structures de tagging comme celle des moyens de paiement.
https://wiki.openstreetmap.org/wiki/FR:Key:payment
payment:MoyenDePaiement=yes/no
du genre :
payment:cash=yes
payment:cheque=no
payment:meal_voucher=yes
payment:sms=no

ce qui donnerait une structure (simple idée, à discuter plus largement
avant de se lancer) :
"adapted_vehicle":"type1"=yes | no
"adapted_vehicle":"type2"=yes | no


> je tente de repérer les emplacements de stationnement réservés.

au niveau des tags du parking en entier, on peut utiliser :
amenity=parking
+ capacity="number"
+ capacity:disabled=yes | no | "number"
au niveau de la place de parking individuelle :
amenity=parking_space
+ parking_space=disabled
+ wheelchair=yes
+ width=3

voir exemple, avec pictogramme pour signaler les places de
stationnements et les tags associés :
https://www.openstreetmap.org/way/266100309 et
https://www.openstreetmap.org/node/4862006223

voir surtout, la même zone avec pictogramme pour signaler les places
réservées, sur le rendu FR :
http://tile.openstreetmap.fr/?zoom=19=44.79525=-0.61734=B00FF

mais aussi :
https://carte.cartomobilite.net/t/ed1d5a-Places_PMR

Certaines personnes bien actives dans les contributions sur les
thématiques accessibilité et accompagnement sont peut-être en congés.
N'hésite à poursuivre la discussion ici, ou sur le
forum.openstreetmap.fr, à solliciter de l'aide ou des idées,
maintenant ou à la fin des vacances :)

-- althio

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

Re: [OSM-talk-fr] Présentation rapide

[althio]

Je n'ai rien trouvé de pertinent dans mes premières recherches, il est
donc peut-être temps que "créer" ce tag.

Mais des structures proches existent déjà, je conseille de s'inspirer
cette page :
https://wiki.openstreetmap.org/wiki/FR:Key:social_facility#Les_b.C3.A9n.C3.A9ficiaires
avec des tags du type :
social_facility:for=disabled

Il existe aussi l'équivalent avec
https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dcommunity_centre
community_centre:for=*
Marc mentionne aussi les centres de formation, je n'ai pas trouvé la
façon de faire.

Dans le cas de l'école de conduite, cela donnerait potentiellement :

amenity=driving_school
+ driving_school:for=disabled

Pour les aménagements, peux-tu détailler les possibilités, qu'on sache
ce que tu cherches à caractériser ?

-- althio


2018-07-22 19:38 GMT+02:00  :
> Bonjour ici,
>
> Je viens de m'inscrire sur la liste suite à un message que j'avais
> envoyé à contact. Et Noémie Lehuby m'a conseillé de vous rejoindre.
>
> J'ai un compte openstreetmap de puis bien longtemps et je participe
> comme je peux en taguant avec les différentes applications mobiles que
> j'utilise ou en signalant les travaux et changement de sens de voies
> autour de moi.
>
> Pour tout vous dire, je suis handicapé et donc les problèmes
> d’accessibilité me touche de prêt (et c'était l'objet de ma question
> initiale).
>
> J'ai longtemps cherché une auto-école PMR, c'est à dire qui dispense des
> cours de conduite aux personnes en situation de handicap, ce qui n'a
> rien à voir avec l'accessibilité du lieu (pour preuve, celle que j'ai
> trouvé ne l'est point).
>
> Je me demandais comment taguer les auto-écoles qui ont ce genre de
> prestations et surtout quels sont les aménagements dont elles disposent.
> En effet toutes n'ont pas la panoplie complète des aménagement possible.
>
> Voilà pour ma présentation.
>
> Jacques
>
> ___
> 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] Recherche ressources pour présentation

[althio]

Voilà quelques présentations généralistes, pour d'éventuelles
inspirations ou ressources.

> S'il existe d'autres ressources utiles à mon projet, je suis preneuse aussi.

https://www.slideshare.net/cartocite/introduction-openstreetmap
https://prezi.com/9fdmnyvtjei_/openstreetmap-octobre-2015/
https://www.slideshare.net/cartocite/openstreetmap-pour-le-tourisme
https://fr.slideshare.net/FIATLUX777/osm-nancy-libresurlaplace-novembre-2017-93175651
https://www.slideshare.net/BenoitFournier/la-donne-participative-et-ouverte-en-gographie-openstreetmap-acg
http://numetlib.fr/wp-content/uploads/2016/11/presentation_apports_openstreetmap.pdf
http://pdfext.github.io/OSM/CoopInfoLab/Presentation_OSM_CFF.pdf
https://www.slideshare.net/napo/openstreetmap-an-introduction-for-the-mappathon-piemonte-visual-contest

Benoît

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

Re: [OSM-talk-fr] Carte scolaire

[althio]

Pour la France, à la louche :
1000 lycées généraux
500 lycées professionnels
5000 collèges
45000 écoles élémentaires + maternelles + primaires

Chacun sa zone.
Chacun son autorité (de municipale à régionale).
Chacun sa source (en open data ou pas).

Les limites sont mises à jour au besoin, en fonction de la
démographie, donc potentiellement toutes les années scolaires.

L'exemple de Paris, uniquement collèges et lycées :
http://www.cartescolaire.paris/

(Mon avis : il faudrait commencer par vérifier les établissements
avant de passer à la carte scolaire)

- althio


2018-03-09 22:03 GMT+01:00 marc marc <marc_marc_...@hotmail.com>:
> Je pense aussi que cela a sa place mais que la maintenance
> est à prendre en compte.
> A quelle fréquence cela change-t-il ? combien de zone y-a-t-il ?
> Si c'est élevé, croire que c'est maintenable à la main est peu réaliste.
> par conséquent cela finit par être périmé (comme les codes insee sur les
> villages des communes périmés) et au final on croit avoir des données
> mais elles sont fausse.
> donc le mieux, c'est de prévoir dès le début un mécanisme complet
> import+maintenance
> - avoir une source opendata qui se met à jour lors des modifs
> - avoir un schéma simple mais précis pour les tags (on a vu dans
> le passé des propositions "usine a gaz" sur des sujets connexes)
> - avoir un outil qui fait à la fois l'import en utilisant un maximum
> les objets déjà présent dans osm, mais qui soie également capable
> de traiter les maj.
> - avoir un peu de doc sur l'outil en question parce qu'un jour la
> personne initiale serra malade/absente/loin d'osm, bref n'importe quelle
> raison qui fait qu'un autre devrait reprendre la relève temporairement
> ou non.
>
> Le 09. 03. 18 à 19:37, LeTopographeFou a écrit :
>> Bonjour,
>>
>> Perso je pense qu'une carte uMap a encore moins de chance d'être
>> trouvée, maintenue et (re)exploitée que la BDD OSM... De plus cela ferme
>> la porte a des potentiels usages, même si spécialisés (quelles sont les
>> écoles publiques auquel j'ai accès habitant à Truc-Muche ?). C'est une
>> force d'OSM que de savoir proposer les données consolidées aux
>> utilisateurs pour bâtir leur propres services géographiques, par rapport
>> aux alternatives commerciales (gratuites ou payantes) et à la
>> proliférations des portails de données géographiques locales (qui
>> s'adressent d'avantage à des développeurs). Les données ne sont pas
>> maintenues tant qu'elles ne sont pas accessibles et utilisées, voila le
>> problème (si personne n'utilise le tag opening_hours, on ne risque pas
>> de découvrir que l'horaire d'ouverture à changé... et si personne
>> n'ajoute ce tag à un magasin, personne ne saura si le magasin est ouvert
>> ou pas à un instant T...). Donc la maintenance pour moi n'est pas là le
>> débat (sinon on ne mettrait rien, pas même les frontières ou rivages).
>> Mettre des données pertinentes dans OSM c'est bien, mais leur donner
>> ensuite une visibilité et un usage, c'est mieux afin de permettre et
>> encourager leur maintenance. Perso quand je tombe sur un fond de carte
>> (libre) intéressant mais que je me dis qu'aucun outils n'est fait pour
>> mettre en valeur cette information, je m’abstiens de la verser au projet.
>>
>> Les cartes scolaires touchent potentiellement tous les français, même si
>> c'est surtout ceux en situation de scolariser leurs enfants. La carte
>> umap en question semble être issue d'une instance officielle de la ville
>> de Mayenne, ce qui je l'espère garanti sa qualité et sa pérennité, mais
>> le danger pour un particulier de faire une carte dans son coin est de
>> laisser trainer sur Internet une carte erronée ou obsolète sans
>> possibilité d'y collaborer. De même le danger d'utiliser un schéma de
>> tag qui n'est pas commun et n'est supporté par aucun outils.
>>
>> Le débat est plutôt de savoir si il existe une manière unifiée et
>> documentée pour, au moins en France, cartographier les cartes scolaires.
>> Si il n'y en a pas, alors elle peut être proposée (en se basant sur des
>> tags existants) et soumise au vote.
>>
>> Cordialement,
>>
>> LeTopographeFou
>>
>> Le 09/03/2018 à 16:09, Xavier Cremaschi a écrit :
>>> Bonjour,
>>>
>>> si je veux rajouter une carte scolaire, par ex en m'appuyant sur :
>>>
>>> http://www.deliberations.antibes-juanlespins.com/files/20170519-1500/11_1_modif_carte_scolaire_vieille_ville.pdf
>>>
>>>
>>> Ça se passe sur la db officielle (donc sur openstreetmap.org ), ou
>>> alors il faut faire des trucs à part comme sur :
>>>
>>> https:/

Re: [OSM-talk-fr] Aéroport fantôme à Plouarzel

[althio]

Cela semble être un petit aérodrome, pour l'aéromodélisme.
https://www.openstreetmap.org/node/5325769632#map=19/48.42230/-4.69680=N

- althio

2018-03-09 10:16 GMT+01:00 François <francois.le@free.fr>:
> Bonjour,
>
> Je viens de constater, avec Qlandkarte, que quelqu'un a taggé un aéroport
> inexistant ici :
> N48° 25.343 W04° 41.822
>
> --
> Cordialement
> 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] OpenStreetMap France est un chapitre local de la fondation OSMF

[althio]

> Félicitations !
>
> Mais je pense qu'en français, le terme à utiliser est section, ou branche.
> "section française de la fondation OSMF" sonne beaucoup mieux, non ?
>
> cf http://www.larousse.fr/dictionnaires/anglais-francais/chapter/569480
> , traduction n° 4.

Merci Jean-Claude pour tes félicitations et ta suggestion.

J'ai choisi "chapitre local" comme traduction de "local chapter" en
suivant l'usage de Wikimedia/Wikipedia.
https://meta.wikimedia.org/wiki/Wikimedia_chapters/fr

Pour la référence, c'est dans mon esprit une extension d'usage de
l'assemblée locale, typique des ordres religieux.

Si nous omettons la référence au religieux, j'aime bien cet usage dans
le sens : "Assemblée que tiennent les (membres) pour délibérer des
questions qui sont de leur ressort ou qui touchent à la vie de la
communauté"

par exemple 1.d. et extension libre de 3. dans
https://fr.wiktionary.org/wiki/chapitre
ou C. extension de A. et A.1. dans
http://stella.atilf.fr/Dendien/scripts/tlfiv5/visusel.exe?82;s=4027537575;r=2;nat=;sol=1;
ou 2. dans le Dictionnaire de l'Académie, neuvième édition
> CHAPITRE n. m.
> 2. (...)
> Par ext. Assemblée que tiennent les chanoines, les religieux ou les 
> religieuses pour délibérer des questions qui sont de leur ressort ou qui 
> touchent à la vie de la communauté. Assembler, convoquer le chapitre. Aller 
> au chapitre. Tenir chapitre. Présider le chapitre. Chapitre conventuel.
> Chapitre provincial, général, dans certains ordres religieux. Le chapitre 
> unanime en a ainsi décidé.
> Avoir voix au chapitre, avoir le droit d'être consulté, de donner son 
> suffrage dans une telle assemblée et, fig., avoir autorité ou qualité pour se 
> mêler d'une affaire, pour peser sur une décision. [...]
> Par anal. Se dit aussi des assemblées tenues par les dignitaires de certains 
> ordres de chevalerie. Un chapitre de l'ordre de Malte.

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

Re: [OSM-talk-fr] Écluses et portes à flots

[althio]

Oui, il faudrait aller chercher l'avis des anglophones natifs.

Pourquoi pas faire la page wiki waterway=tidegate puis notifier sur
tagging, ou l'inverse ;)

De mon côté, pour "floodgate", je ne prendrais pas "flood"
littéralement pour "inondations", mais aussi "montée des eaux",
"débordement", "trop-plein".
Et pour moi on est totalement dans le contrôle d'écoulement (flow
control). Il y a d'autres installations qui sont clairement du "flood
protection".
Je vous laisse vous faire votre opinion, j'ai lu cela :

http://www.wordreference.com/definition/floodgate
[English] floodgate /ˈflʌdˌɡeɪt/ n. Also called: head gate, water gate
1. a gate in a sluice that is used to control the flow of water
2. (often plural: floodgates) a control or barrier against an outpouring or flow
[American] floodgate /ˈflʌdˌgeɪt/   n. [countable] Civil Engineering
1. gate regulating the flow of water.
2. anything serving to control the passage of something

http://www.wordreference.com/synonyms/floodgate
floodgate, sluice gate

http://www.wordreference.com/enfr/floodgate
floodgate n
often plural (gate preventing overflow of water) vanne, porte d'écluse
floodgates npl
figurative (barrier) barrière


En bonus, tout ce que j'ai pu pêcher dans taginfo :

waterway=lock_gate 17 359
waterway=sluice_gate 204
waterway=floodgate 170
waterway=former_lock_gate 12
waterway=gate 5
waterway=stuice_gate 3
waterway=headgate 3
waterway=stuice_gateream 2
waterway=former lock_gate 1
waterway=dock_gate 1
waterway=security_gate 1
waterway=sluicegate 1

waterway=flow_control 261
flow_control=sluice_gate 194
flow_control=water_level 22
flow_control=overflow 12
flow_control=bottom_outlet 11
flow_control=discharge 9
flow_control=entry 3
flow_control=over_flow 2
flow_control=traffic_lights half duplex 1
flow_control=moench 1
flow_control=sluice 1
flow_control=flood_gate 1

gate=flood_wall 6
gate=flood_defence 3
gate=flood_gate 2

seamark:gate:category=lock 295
seamark:gate:category=flood_barrage 51
seamark:gate:category=sluice 29
seamark:gate:category=general 3
seamark:gate:category=dyke 3
seamark:gate:category=caisson 3

2018-01-10 22:17 GMT+01:00  <osm.sanspourr...@spamgourmet.com>:
> oups, j'avais lu flowgate. Comme quoi rien ne sert d'être plus fluent !
>
> Oui, ça correspond protections anti-inondations.
>
> Flood control et non flow control.
> flow_control=water_level ? contrôle du niveau de l'eau
> waterway=low_weir ? seuil bas
>
> Semblent là aussi surtout utilisé en eaux douces.
>
>
> Le 10/01/2018 à 20:44, Vincent Bergeot - vinc...@bergeot.org a écrit :
>
> Bonsoir,
>
> ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
> l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
> en anglais !!!).
>
> Alors que les portes à flots j'ai l'impression que c'est quelque chose de
> plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
> exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
> (zone marécageuses par exemples).
>
>
>
> Le 10/01/2018 à 01:05, osm.sanspourr...@spamgourmet.com a écrit :
>
> Ça me plait, ça pourrait être utilisé pour les formes de raboub et les seuil
> des ports me semble-t-il.
>
> Pour le moment mes recherches sur Brest et Lorient n'ont rien donné : on a
> des eaux ou des formes de raboub mais la séparation se fait par la vertu du
> Saint-Esprit.
>
> Comme je ne crois pas trop à sa vertu, je préfère ajouter un tag.
>
> Il faudrait presque une info complémentaire car certaines "écluses" sont
> faites pour faire entrer l'eau de mer, d'autres pour faire sortie l'eau
> douce d'autres pour simplement contrôler le niveau style chasse de la baie
> du mont Saint-Michel.
>
>
> Le 10/01/2018 à 00:16, althio - althio.fo...@gmail.com a écrit :
>
> waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki
>
>
> ce qui m'intrigue avec floodgate c'est que cela semble surtout lié à de
> l'inondation, du déluge (de ce que j'ai compris je ne suis pas assez fluent
> en anglais !!!).
>
> Alors que les portes à flots j'ai l'impression que c'est quelque chose de
> plus régulier, à chaque marée, soit pour maintenir de l'eau dans un port par
> exemple soit pour empêcher l'eau de mer de venir "polluer" de l'eau douce
> (zone marécageuses par exemples).
>
>
> Le 10/01/2018 à 00:16, althio a écrit :
>
>
> Par analogie, il faudrait quelque chose comme waterway=tidal_gate
>
> tide gate ou floodgate semble plus courant en anglais.
>
> waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki
>
>
> à votre avis on part plutôt sur floodgate parce que cela existe déjà ou sur
> un tidegate car plus lié au marée
>
> à plus
>
&

Re: [OSM-talk-fr] Précision ou non de la valeur par défaut de maxspeed pour les living_street en France

[althio]

Bonjour Charles,

Les valeurs par défaut sont explicites dans la relation suivante :
https://www.openstreetmap.org/relation/934933

Cela est documenté dans la page
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#Default_speed_limits
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed#France

Peut-être que cela répond partiellement à ta question.

2018-01-17 14:54 GMT+01:00 Charles MILLET :
> Un contributeur a précisé l'information suivante dans la page du Wiki
> FR:Bicycle
>
> "Utiliser l'attribut highway=living_street, l'attribut maxspeed=20 n'est pas
> nécessaire car valeur par défaut en France"
>
> De mon point de vue, c'est nécessaire d'expliciter le maxspeed et de ne pas
> se basé sur les spécificités locales pour considérer des valeurs implicites
> de cette importance. Mais je voulais avoir vos avis avant d'en parler dans
> la partie discussion ou directement avec le contributeur. Bon je pense que
> le sujet a déjà du être beaucoup débattu mais comme je n'ai pas trouvé de
> référence claire, ça pourra faire l'objet d'un rappel :)
>
> --
> Charles MILLET
> charlesmil...@free.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] dépose-minute

[althio]

Il y a clairement un manque pour définir ces zones et voies de dépose-minute :
En français, belle brochette de name=*
https://taginfo.openstreetmap.org/search?q=d%C3%A9pose+minute#values

Côté anglais, kiss_and_ride est mignon, un terme moins romantique
existe : drop off.

On retrouve donc également des déclinaisons autour de "drop off" dans les tags :

un bon candidat :
https://taginfo.openstreetmap.org/tags/service=drop_off

et d'autres :
https://taginfo.openstreetmap.org/tags/amenity=passenger_pick_up_drop_off
https://taginfo.openstreetmap.org/tags/?key=name=Passenger%20Pick-Up%2FDrop-Off
https://taginfo.openstreetmap.org/tags/?key=name=Passenger%20pick-up%2Fdrop-off
https://taginfo.openstreetmap.org/tags/?key=name=Passenger%20pick%20up%2Fdrop%20off
https://taginfo.openstreetmap.org/tags/?key=name=Pick%20up%2FDrop%20off
https://taginfo.openstreetmap.org/tags/?key=name=Drop%20Off%2FPick%20Up
https://taginfo.openstreetmap.org/tags/?key=name=FWTC%20Drop%20Off%20%2F%20Pick%20Up%20Lane
https://taginfo.openstreetmap.org/tags/note=no%20parking%20-%20only%20for%20drop-off%20and%20pick-up

Rien n'est encore documenté
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice
mais c'est mon candidat :
highway=service + service=drop_off
+ fee... + maxstay...

-- althio


2018-01-14 20:48 GMT+01:00  <osm.sanspourr...@spamgourmet.com>:
> dépose-minute se dit kiss and ride en anglais.
>
> Mot que l'on trouve :
>
> - sur le wiki... en espagnol pour no_parking. Mais c'est juste pour signaler
> une tolérance.
>
> - kiss_and_ride=yes (2 occurrences dans le monde).
>
> Ne devrait-on pas proposer la création de cette clé (et par analogie avec
> les autres clés de parking, capacity:kiss_and_ride) pour indiquer un endroit
> fait pour la dépose-minute ?
>
> Voir amenity=kiss_and_ride si on veut les distinguer des places de parking
> comme on le fait avec les places de taxi puisque ce n'est pas une vraie
> place de parking, il est fréquent que le conducteur doive rester à bord du
> véhicule.
>
> Je suis étonné de n'avoir rien trouvé car les dépose-minute sont fréquentes
> près des gares et des aéroports.
>
> Jean-Yvon
>
>
> ___
> 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] Challenge ? Si on dégommait du rose ?

[althio]

Pour le millésime ou la date de prise de vue des imageries :
- Bing donne la date en metadata, accessible dans iD "Vintage" et JOSM
"capture date"
- BDOrtho, la date est disponible ici :
http://umap.openstreetmap.fr/fr/map/date-heure-des-prises-de-vues-aeriennes-de-la-bd-o_160764


Christian Quest 
Date: 2017-07-29 20:42 GMT+02:00
Subject: [OSM-talk-fr] Une carte uMap de datation de la BD Ortho...
To: Discussions sur OSM en français 


Si vous voulez savoir de quand datent les images aériennes de la BD
Ortho sur une zone donnée, voici une carte uMap qui vous sera utile:

http://umap.openstreetmap.fr/fr/map/date-heure-des-prises-de-vues-aeriennes-de-la-bd-o_160764

On a la date et l'heure de prise de vue et donc ceci permet de
connaitre la fraîcheur de ce qu'on voit.
Attention, c'est semble-t-il valable sur la résolution à 50cm/pixel,
au delà, les images peuvent provenir d'une autre campagne plus
ancienne.

[...]

2018-01-13 11:37 GMT+01:00 George Kaplan :
>>
>> Le 13 janv. 2018 à 10:43, erwan salomon  a écrit :
>> […]
>> vous avez une source sous JOSM pour obtenir un cadastre plus récent que 2015 
>> ? (j’utilise tes.cadastre.openstreetmap.fr mais ça semble bloqué à 2015)
>> pareil pour les photos aérienne ça tourne au mieux vers 2013 (Esri souvent 
>> un peu plus récent que IGN)
>
> J’ai remarqué récemment que l’imagerie Bing est plus récente que BDOrtho. 
> Dans le cas en question (Saint-Malo), par connaissance des évolutions du 
> terrain, j’ai estimé la vue Bing à l’année 2017. La résolution de cette 
> imagerie est néanmoins moins bonne que BDOrtho.
>
> ___
> 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] conférence FOSS4G-fr du 15 au 17 mai 2018

[althio]

---

L'OSGeo-fr organise le prochain FOSS4G-fr du 15 au 17 mai 2018, à
l’École Nationale des Sciences Géographiques, Marne-la-Vallée - Paris.


Opportunité unique de rencontres, cet événement s'adresse à tous les
acteurs de l'écosystème GéoSpatial Opensource francophone : décideurs,
utilisateurs, développeurs.


Cette 3ème édition se déroulera sur 3 jours : 2 jours de conférences
précédés d’une journée d’ateliers, sur des thématiques volontairement
larges et inspirantes !


A ce stade, vous pouvez d’ores et déjà :

Prendre date !

Soumettre présentation ou atelier ;

Devenir sponsor de l’événement.


L’ensemble des informations sur le site : foss4g.osgeo.fr


Nous comptons sur vous !


En vous remerciant,


L’équipe organisatrice, @FOSSGFR


---

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

Re: [OSM-talk-fr] Écluses et portes à flots

[althio]

> sluice_gate c'est plutôt la vanne, l'écoulement que la porte en elle-même ?

"sluice" c'est le canal d'écoulement, mais "sluice gate" c'est la porte.

> Par analogie, il faudrait quelque chose comme waterway=tidal_gate

tide gate ou floodgate semble plus courant en anglais.

waterway=floodgate existe aussi dans osm/taginfo, pas dans osm/wiki



2018-01-09 16:14 GMT+01:00 Vincent Bergeot <vinc...@bergeot.org>:
> Bonjour et merci pour vos réponses !
>
>
> Le 08/01/2018 à 21:02, althio a écrit :
>>
>> Bonsoir Vincent,
>>
>> Je te suggère :
>>
>> # waterway=flow_control + flow_control=sluice_gate
>> ou directement
>> # waterway=sluice_gate
>>
>> La première version vient d'une proposition inachevée, mais utilisée :
>> https://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate
>> https://taginfo.openstreetmap.org/tags/waterway=flow_control
>> https://taginfo.openstreetmap.org/keys/flow_control
>>
>> La deuxième version est également utilisée dans les mêmes proportions,
>> bien que non référencée sur le wiki.
>> https://taginfo.openstreetmap.org/tags/waterway=sluice_gate
>>
>> -- althio
>
>
> j'ai l'impression que l'on est surtout sur la régulation avec exclusivement
> de l'eau douce (mais peut-être que je me trompe) et dans le cas du
> sluice_gate c'est plutôt la vanne, l'écoulement que la porte en elle-même ?
>
> waterway=flow_control : http://overpass-turbo.eu/s/upl
> waterway=sluice_gate : http://overpass-turbo.eu/s/upm
>
> Le 08/01/2018 à 18:37, marc marc a écrit :
>>
>> Le 08. 01. 18 à 18:06, Vincent Bergeot a écrit :
>>>
>>> les écluses j'ai trouvé un tag
>>> (https://wiki.openstreetmap.org/wiki/FR:Key:lock) mais c'est axé sur la
>>> navigation sur rivière ou cours d'eau.
>>>
>>> Mais je n'ai pas trouvé pour ces portes à flots, auriez vous une idée,
>>> suggestion ?
>>
>> si je lis bien, lock dit juste que la portion de canal est entourée de
>> porte. les écluses elle-même étant waterway=lock_gate
>>
>> Par analogie, il faudrait quelque chose comme waterway=tidal_gate
>
>
> effectivement cela me semble être plus approprié mais inexistant aujourd'hui
> dans taginfo.
>
> Bon je vais continuer à creuser et surtout voir celles des landes de mes
> yeux !!!
>
> merci
>
>
> --
> Vincent Bergeot
>
>
> ___
> 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] Écluses et portes à flots

[althio]

Bonsoir Vincent,

Je te suggère :

# waterway=flow_control + flow_control=sluice_gate
ou directement
# waterway=sluice_gate

La première version vient d'une proposition inachevée, mais utilisée :
https://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate
https://taginfo.openstreetmap.org/tags/waterway=flow_control
https://taginfo.openstreetmap.org/keys/flow_control

La deuxième version est également utilisée dans les mêmes proportions,
bien que non référencée sur le wiki.
https://taginfo.openstreetmap.org/tags/waterway=sluice_gate

-- althio


On Jan 8, 2018 6:07 PM, "Vincent Bergeot" <vinc...@bergeot.org> wrote:

Bonjour,

les portes à flots ou porte à marais permettent la régulation entre
une source d'eau douce et une source marine. Cela présente des
similitudes avec des écluses.

Autant pour les écluses j'ai trouvé un tag
(https://wiki.openstreetmap.org/wiki/FR:Key:lock) mais c'est axé sur
la navigation sur rivière ou cours d'eau.

Mais je n'ai pas trouvé pour ces portes à flots, auriez vous une idée,
suggestion ?

Pour infos sur les portes à flots/marais :

https://www.futura-sciences.com/planete/definitions/developpement-durable-porte-maree-6891/
https://www.ouest-france.fr/normandie/carentan-50500/carentan-les-portes-flots-sur-la-taute-en-passe-detre-deplacees-3679657
http://www.parc-cotentin-bessin.fr/fr/patrimoine-hydraulique---les-portes-a-flot-gc195.html

Bonne journée

-- 
Vincent Bergeot


___
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] adresses en France et StreetComplete [dérivé de Re: schéma des addr]

[althio]

althio :
>> Il me semble que l'auteur de StreetComplete (application Android de
>> collecte et contribution) aurait besoin d'information sur les
>> pratiques "adresses" en France... de manière à décider si son
>> application devrait ou ne devrait pas proposer des modifications
>> concernant les adresses en France.

Quand je parle de *pratiques "adresses" en France*, je veux faire
référence aux *pratiques _de cartographie sur OSM_ des adresses en
France*.

Pour bien comprendre le contexte et les attentes dans StreetComplete,
il faut vraiment aller sur le ticket
https://github.com/westnordost/StreetComplete/issues/714#issuecomment-353980856

Philippe Verdy :
> Il y a déjà de bons sites pour expliquer les règles compliquées des adresses
> et surtout pour liste des fausses règles contredites par la réalité.
>
> Cela a été fait en anglais d'abord car on a presque tous les cas compliqués
> au Royaume-Uni et toutes les exceptions. Un de ces auteurs est a été
> [...]

Ce n'est pas le fond de ma question, à la limite un lien vers un de
ces sites pour référence aurait pu être intéressant.
Le sujet de ce fil est plutôt : Est-ce que StreetComplete doit adapter
son comportement (=désactiver une quête spécifique) par rapport aux
pratiques de cartographie en France, pour éviter des doublons ou une
baisse de qualité ?

-- althio

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

Re: [OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[althio]

2018-01-06 11:37 GMT+01:00 François Lacombe <fl.infosrese...@gmail.com>:
> Bonjour Althio,
>
> Je ne connaissais pas ce projet.
> Qu'en est-il de son adoption dans les différents éditeurs ?

Il est la référence pour iD, Potlatch 2 et Vespucci. C'est à
configurer pour JOSM qui maintient une liste à part.

cf. https://github.com/osmlab/editor-layer-index/blob/gh-pages/README.md
> If you are using iD, Potlatch 2 or Vespucci, you are already using this index!
> For JOSM you can add http://osmlab.github.io/editor-layer-index/imagery.xml 
> to the preference key imagery.layers.sites in advanced preferences. You 
> probably want to remove the https://josm.openstreetmap.de/maps entry or 
> you'll get the same layers listed twice.

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

Re: [OSM-talk-fr] Organisation des sources photos aeriennes sur Wikidata

[althio]

Bonjour François,

Ma réponse est hors-sujet pour wikidata, mais pour une liste de fonds
d'imagerie pour OSM il y a :
https://github.com/osmlab/editor-layer-index

Mais peut-être aviez-vous d'autres idées en tête.

-- althio


2018-01-06 10:16 GMT+01:00 François Lacombe <fl.infosrese...@gmail.com>:
> Hello à tous,
>
> Hier matin j'ai eu le plaisir de partager un TGV avec un ami lyonnais (Alain
> Ruet) qui contribue également sur OSM et on a eu quelques idées ensemble.
>
> Notamment celle d'harmoniser les sources d'orthophoto pour les éditeurs, en
> inventoriant les serveurs WMS disponibles sur Wikidata.
> Ainsi JOSM, iD et d'autres pourraient puiser là-dedans pour compléter leur
> liste sans que nous ayons à compléter un fichier pour chaque projet (avec un
> format différent).
>
> Cela permettrait dans un deuxième temps de sourcer les changeset avec plus
> de précisions, par exemple l'année ou la finesse des photos (connus de
> wikidata via la ref qu'on indique dans le changeset).
> Un utilisateur qui éditerait des objets avec une vue aérienne moins précise
> (Bing) que celle à partir de laquelle la dernière version a été établie
> (Orthophoto locale) pourrait être averti.
>
> Je lance ça en l'air, ne connaissant pas vraiment la manière de déclarer de
> nouveaux types d'objets dans wikidata. Peut-etre que c'est même déjà fait ?
> Qu'en pensez-vous ?
>
> 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

[OSM-talk-fr] adresses en France et StreetComplete [dérivé de Re: schéma des addr]

[althio]

Il me semble que l'auteur de StreetComplete (application Android de
collecte et contribution) aurait besoin d'information sur les
pratiques "adresses" en France... de manière à décider si son
application devrait ou ne devrait pas proposer des modifications
concernant les adresses en France.

Voir (et intervenir ?) sur
https://github.com/westnordost/StreetComplete/issues/714#issuecomment-353980856

Vos avis ?

-- althio


2018-01-05 14:04 GMT+01:00 Christian Quest <cqu...@openstreetmap.fr>:
> Marc, tu te trompe sur plusieurs points.
>
> contact:* est documenté et l'était bien avant qu'on en parle ici. Il s'agit
> bien d'indiquer pour un POI le moyen de le contacter, pas que via son
> adresse. Séparer la définition de l'adresse et celle du POI est assez
> logique.
>
> Les deux schémas utilisé pour modéliser les adresses sont largement
> utilisables, que ce soit avec les relations ou sans.
>
> On peut tout à fait relancer la discussion, mais comme les éléments de
> départs n'ont pas changé, je ne vois pas pourquoi on arriverait à une autre
> conclusion.
>
>
> Il ne faut pas tout mélanger. Là, le départ c'est une anomalie signalée à
> juste titre par osmose (si j'ai bien suivi) avec des modifications faites à
> moitié.
>
>
> Les adresses ça semble simple, mais en même temps c'est complexe, ce que
> j'ai découvert en bossant ces dernières années sur le sujet. Pour beaucoup
> de monde il y a confusion entre adresse et bâtiment (d'où cette tendance à
> mettre des adresses sur les polygones de bâtiments) alors que non, ça n'est
> pas du 1 vers 1.
>
> J'ai encore dû expliquer à un dev ce matin qui réalisait un écran de saisie
> d'adresse sur une borne que non, les codes postaux ne correspondent pas à
> une commune... qu'il y a environ 6000 codes postaux et plus de 35000
> communes (CQFD).
>
> Peut être devrions nous mieux expliciter tout ça sur le wiki pour bien faire
> comprendre la logique des adresses, ce qu'elles sont et ne sont pas, etc.
>
>
>
> Le 5 janvier 2018 à 13:15, marc marc <marc_marc_...@hotmail.com> a écrit :
>>
>> Le 04. 01. 18 à 23:53, osm.sanspourr...@spamgourmet.com a écrit :
>> > une personne a vire le addr:housenumber parce que trop près de la
>> > voirie.
>> > http://www.openstreetmap.org/changeset/35942339
>>
>> le problème est plus large que cela.
>> ce qu'on peux lui reprocher :
>> ses modifs sont incohérente avec le reste de la rue.
>> s'il voulait migrer le nœud addr au profit du bâtiment, il fallait le
>> faire au complet = supprimer totalement ce nœud et remplacer le noeud
>> par le bâtiment dans la relation assosciatedStreet
>> Et idéalement faire toute la rue en une fois pour garder une micro
>> cohérence toute symbolique et absurde que cela soie dans ce cas.
>>
>> L'autre problème, c'est qu'en mettant le nœud quelque part en bordure de
>> la parcelle, on confie au hasard le lien entre une adresse et un bâtiment.
>> Si on veux tager le fait que c'est la parcelle qui a une adresse et non
>> le bâtiment, soyons cohérent de taguer la parcelle (ce qui est hors de
>> portée du contributeur moyen).
>> Mais un tag de nœud mis positionné sans règle précise, c'est la foire.
>> Dans ton lien, il est par exemple impossible de savoir avec certitude
>> l'adresse du bâtiment au sud de la rue du Muguet
>> https://www.openstreetmap.org/node/2045090782#map=19/48.37680/-4.57899
>> peut-être est-ce le 27 à moins que le bâtiment de gauche aie 3 adresses
>> et que celui du bas n'ai pas encore d'adresse renseignée.
>> peut-être même que c'est le 19 Route de Trénen avec une allée privée non
>> renseigne. bref, faut prendre une vue satellite pour essayer de deviner
>> l'adresse
>> La solution de rapprocher le nœud du bâtiment revient implicitement à
>> dire qu'on considère qu'il y a un lien entre l'adresse et le bâtiment
>> tout en étant incohérent dans le fait de ne pas tager ce lien.
>>
>> Par conséquent, il ne faut pas s'étonner que des contributeurs finissent
>> par ajouter les adresses sur les bâtiments lorsque ceux-ci n'ont qu'une
>> adresse ou sur les portes d'entrée.
>> Et on a le même problème avec ceux qui placent les poi à l'entrée de la
>> parcelle (vu hier le cas hier d'un nœud en bord de route pour désigner
>> la présence d'une chambre d'hôte dans un bâtiment des environs)
>> aucun lien avec le bâtiment ni son adresse.. donc les gens finissent
>> par encoder l'adresse une 3ieme fois.
>> certains pensent que ce problème s'évite en utilisant une xieme
>> spécificité franco-francaise des contact:addr documenté nulle part et
>> donc utilisé par aucune app.
>>
>> Perso je suis triste

Re: [OSM-talk-fr] Imagerie de base dans Id

[althio]

Salut Donat,

Nous avons déjà essayé sans succès.

Le problème principal vient de la licence encore trop restrictive de l'IGN
et/ou du système mis en place pour respecter cette licence.
Pour plus de détails, il faut plonger dans l'historique des discussions
(principalement en anglais) :

http://forum.openstreetmap.fr/viewtopic.php?f=5=4715=25
https://github.com/openstreetmap/iD/issues/3420
https://github.com/osmlab/editor-layer-index/pull/194


2018-01-05 0:27 GMT+01:00 Donat ROBAUX :

> Bonsoir,
>
> Je profite du mail de Marc sur les nouveaux pour vous faire part d'une
> interrogation à la suite de mes quelques revues de contributions.
> Les nouveaux contributeurs contribuent majoritairement avec Id. Outre le
> fait de ne pas avoir d'alerte Osmose comme sur Josm (ce qui en soit est
> gênant puisque ca laisse passer des erreurs grossières), je m'aperçois que
> tous contribuent avec l'imagerie Bing.
> Pour faire court, et je pense que vous comprendrez les implications,
> peut-on définir pour la France que l'imagerie par défaut est la BDOrtho IGN?
>
> Donat
>
>
>> -- Message transféré --
>> From: marc marc 
>> To: talk-fr 
>> Cc:
>> Bcc:
>> Date: Thu, 4 Jan 2018 17:33:35 +
>> Subject: Re: [OSM-talk-fr] review_requested=yes sans commentaire pour
>> aider les nouveaux
>> Bonjour,
>>
>> je relance le message car je pense que ce serait utile d'aider ceux qui
>> se posent des questions sur leur contribution.
>> je retourne régulièrement voir ce qu'ils ont fait après mon message,
>> ceux qui continue à être actif ont généralement corrigé leurs erreurs.
>> le lien affiche les nouveaux qui n'ont eu aucun commentaire.
>> > https://resultmaps.neis-one.org/osm-suspicious?country=140;
>> hours=96=10=c=review_requested%
>> 3Dyes=t=>=10=d=n=t
>>
>> si on arrive à traiter cette liste de demande d'aide, on peux toujours
>> changer le critère pour viser + large.
>>
>> Cordialement,
>> Marc
>>
>> Le 02. 12. 17 à 14:35, Marc M. a écrit :
>> > Bonjour,
>> >
>> > Le tag permet à un contributeur qu'il souhaite un 2ieme avis sur sa
>> modif.
>> > Je regarde régulièrement les changeset avec ce tag, le plus souvent
>> > utilisé par un contributeur récent.
>> > C'est un outil pratique pour aider à s'améliorer.
>> > A ma demande, Pascal Neis l'auteur du site web ci-dessous, a ajouté une
>> > option pour n'afficher que les changeset sans commentaire, ceux qui sont
>> > le + susceptible d'avoir besoin d'un coup d’œil.
>> > Pour la France, cela donne
>> >> https://resultmaps.neis-one.org/osm-suspicious?country=140;
>> hours=96=-1=review_requested%3Dyes&
>> anyobj=t=%3E=10=d=n=t#5/46.574/2.878
>> >>
>> >
>> > Cela serait utile qu'on le fasse à plusieurs :)
>> > Pour que cette nouvelle option fonctionne, il faut bien sur prendre la
>> > peine de mettre un petit mot sur le changeset (même quand il n'y a rien
>> > à corriger).
>> > Pour ma part, je constate qu'environ la moitié des réactions sont prise
>> > en compte (j’imagine que les autres ne sont peut-être pas vu que osm
>> > envois uniquement l'info par email, susceptible d'aller en spam, sans
>> > notification via le site)
>> >
>> > Cordialement,
>> > Marc
>>
>>
>>
>
>
> 
>  Garanti
> sans virus. www.avast.com
> 
> <#m_9198483440907708547_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ___
> 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] Question sur le rendu standard !

[althio]

>> Où fait-on remonter ce type de problème (si c'est bien un problème ?) ?
>
> ici https://github.com/gravitystorm/openstreetmap-carto/issues
> et là https://github.com/cquest/osmfr-cartocss/issues

En fait, cela doit déjà être connu :
https://github.com/gravitystorm/openstreetmap-carto/issues/2428
https://github.com/gravitystorm/openstreetmap-carto/issues/2511
https://github.com/gravitystorm/openstreetmap-carto/issues/1465

et voire "au-dessus", améliorations en cours dans les dernières
versions de mapnik
https://github.com/mapnik/mapnik/issues/3550
https://github.com/mapnik/mapnik/issues/3558
https://github.com/mapnik/mapnik/pull/3771
https://github.com/mapnik/mapnik/pull/3811

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

Re: [OSM-talk-fr] Question sur le rendu standard !

[althio]

> Bonjour et bonne année à toutes et tous !

Itou à toutes et itou à tous :)

> dans le rendu carto standard (et fr), le name s'affiche parfois de façon 
> "décalé".

Tout cela est bien bizarre en effet, sacré pioche.

> Où fait-on remonter ce type de problème (si c'est bien un problème ?) ?

ici https://github.com/gravitystorm/openstreetmap-carto/issues
et là https://github.com/cquest/osmfr-cartocss/issues

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

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[althio]

Non tu n'es pas le seul, il suffit d'aller voir la question sur :
https://github.com/gravitystorm/openstreetmap-carto/issues/2931

-- althio


2017-12-28 15:10 GMT+01:00 Vincent Frison <vincent.fri...@gmail.com>:
> Hello,
>
> Je sais pas si je suis le seul mais pour moi les cartes affichant le relief,
> c'est à dire avec hillshade et/ou courbes de niveaux, sont bien plus jolies
> que celles sont relief. Je dirais même qu'en plus d'être plus jolies elles
> sont beaucoup plus claires car elles permettent de se repérer plus
> facilement avec le relief.
>
> Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et je
> trouve ça plus que dommage.
>
> Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le problème
> c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses fonctionnalités
> (principalement celle qui permet de chercher les objets afin de voir tous
> les détails).
>
> Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement le
> relief est assez mal rendu et puis surtout il est vraiment orienté pour les
> vélos en masquant la plupart des informations pour mettre en valeur celles
> utiles aux cyclistes.
>
> J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une option
> pour afficher le hillshade et les courbes de niveaux. c'est à dire 2 petites
> checkboxes en plus de celles existantes (permettant d'afficher les notes de
> carte, etc.).
>
> Sur le site http://opensnowmap.org en allant dans les settings on peut
> afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> l'impression que c'est juste un layer supplémentaire (avec hillshade et
> courbes de niveaux) qui s'affiche en plus de celui du rendu standard.. mais
> qui du coup n'a plus rien à voir avec le rendu classique, pour moi la valeur
> ajoutée est vraiment énorme !
>
> Suis je le seul à qui ça manque ?
>
> Et à qui devrais  je demander cette évolution ? Sur un mailing list
> particulière ou directement en créant une issue ici:
> https://github.com/gravitystorm/openstreetmap-carto ?
>
> Merci, Vincent.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Noms des ZI ZA ZAC etc

[althio]

Est-ce nécessaire de mettre la dénomination (ZAC) dans le nom principal ?
L'information "ZAC" peut être portée par d'autres tags je suppose ?
Est-ce qu'on peut prendre cela comme les cas "Ville de .../Commune de
.../Arrondissement de ..." ?

Je verrai bien du :

name=Trucmuche
alt_name=Zone d'Aménagement Concerté Trucmuche
short_name=ZAC Trucmuche

-- althio


2017-12-16 14:52 GMT+01:00 Paul Desgranges <desgranges.p...@laposte.net>:
> Hello
>
>  Que conseillez vous pour le nommage des ZI, ZA, ZAC, ZC, etc ?
>
>name=Zone d'Activités Trucmuche
>short_name=ZA Trucmuche
>alt_name=Trucmuche
>
> ou plutôt
>
>name=ZAC Trucmuche
>short_name=Trucmuche
>alt_name=Zone d'Aménagement Concerté Trucmuche
>
> ou quoi d'autre ?
>
> Merci!
>
> Paul
>
>
>
>
> ___
> 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] Marquage et jalonnement en randonnée

[althio]

Je suis d'accord avec la ligne de pensée de sly.
Le poteau n'a pas vraiment de "name".

Je verrais plutôt le tag "inscription=*" comme sur les plaques, monuments, …
http://wiki.openstreetmap.org/wiki/FR:Key:inscription

Pourquoi pas faire aussi le lien explicite avec l'élément réel qui porte
effectivement le "name=*", grâce à une relation ou une référence wikidata ?

Le travail de modélisation pour du routage entre poteaux est d'un autre
niveau de complexité. Peut être avec des relations type route. Mais cela
vient clairement après.

-- althio

On Nov 16, 2017 11:28 PM, "sly (sylvain letuffe)" <lis...@letuffe.org>
wrote:

> Pour le rendu qui peut évoluer, ça, j'ai peur que ça soit : ne plus
> afficher
> les name des panneaux !
> Et c'est pas une erreur du rendu vu que ce qui est écrit sur le panneau
> c'est le nom du col non loin, pas le nom du panneau.
>
>
> emeric Prouteau wrote
> > Par contre ne pas les indiquer serrait à mon avis dommage car si on
> > indique
> > des relations de type direction_sign pour un éventuel futur outil de
> > routing de rando, le nom d'un bois (Décrivant le bois) identique au nom
> > d'un poteau serait moins précis que le poteau qui correspond lui à une
> > distance précise par rapport à un autre poteau.
>
> J'entrevois l'idée derrière qui consisterait à réduire le bois, le lac,
> bref
> une surface à un point afin d'avoir des temps de marche plus précis depuis
> le précédent panneau, mais je vois bien l'embrouille qui peut naître du cas
> suivant : Si ton bois est assez large (disons qu'il faut 30mn pour le
> traverser) y'a de grande chance qu'on trouve des panneaux à chaque entrée
> du
> bois.
>
> A--15mn-Bois--30mn---Bois--15mn--B
>
> Depuis B il faut 15mn pour aller au bois, depuis A 15mn aussi, mais pour
> faire A->B il faudra 1h.
> Bref, derrière cette louable idée d'aider un "routeur de rando" j'ai peur
> que tant qu'on l'a pas codé, on ne crééer une distorsion de la réalité qui
> au contraire embrouille l'usage qui peut en être fait. Surtout quand le
> panneau commence à se situer de plus en plus loin de l'objet qu'il indique.
>
> Bon, si encore ça ne restait qu'une donnée morte, on pourrait tenter le
> coup
> et attendre que quelqu'un s'en serve, mais j'ai plusieurs exemple ou le
> name
> est mis sur le panneau par le contributeur, et, pensant qu'il a fait le
> nécessaire, ne l'ajoute pas sur l'objet indiqué.
> Ou constate qu'un panneau avec ce nom existe déjà dans OSM ne saisi pas le
> col, le sommet, le bois.
>
> Bref, je reste pour l'instant sur l'idée que ça fait plus de mal que de
> bien.
>
>
>
>
> -
> --
> sly, contact direct : sylvain /a\ letuffe o r g
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ancien chemin plus utilisable : suppression ou tag ?

[althio]

JB
> J'opte pour le "disused:highway=*". Si le chemin est rouvert un jour, il n'y
> a qu'un tag à changer. Sur les rendus classiques, il n'est pas présent.
> Et quand j'essaye d'y passer, j'ai souvent un sécateur. Au bout de quelques
> fois, il repasse en highway=path…

+1

cela reflète la réalité du terrain,
c'est toujours dans la base pour qui veut chercher ce type d'éléments
(entretien, veille des riverains, promeneurs et associations),
en cas d'entretien plus régulier, le chemin peut être facilement mis à jour.

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

Re: [OSM-talk-fr] Tagger un bazar d'été, qui vend des articles de plage, des jouets...

[althio]

2017-07-15 15:59 GMT+02:00 Nicolas Toublanc :
> Si on reste sur l'idée plus générale d'un bazar (indiquée sur la devanture
> des magasins en question: "Bazar, jeux, articles de plages"),
> shop=variety_store semble bien convenir, et est très fréquent

+1


> 2017-07-13 21:32 GMT+02:00 :
>>
>> Les plages ne sont pas à vendre ! ;-)

Même commentaire pour shop=golf ou shop=sports ? ;-)

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

Re: [OSM-talk-fr] Tagger un bazar d'été, qui vend des articles de plage, des jouets...

[althio]

Si j'osais, je te dirais d'utiliser
shop = beach

Tu ne serais pas le premier, même si c'est rare.
https://taginfo.openstreetmap.org/search?q=shop%3Dbeach

Si j'osais encore plus, je te dirais de documenter ça dans le wiki :)
http://wiki.openstreetmap.org/wiki/Category:Shops
http://wiki.openstreetmap.org/wiki/Tag:shop%3Dbeach



2017-07-12 9:17 GMT+02:00 Nicolas Toublanc :
> Bonjour,
>
> Je ne sais pas trop comment tagger un bazar de bord de mer, qui vend surtout
> des jouets et articles de plages.
>
> Des jouets, ça fait penser à autre chose (spécialité jouets, alors qu'ici on
> a juste quelques ballons et jouets de plage):
> http://wiki.openstreetmap.org/wiki/Tag:shop%3Dtoys
>
> Souvent on y trouve aussi des souvenirs, mais pas toujours, et parfois c'est
> très secondaire: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dgift
>
> Merci!
>
> --
> Nicolas Toublanc
>
> ___
> 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] [OCM] Pourquoi "cycleway:left=opposite_lane" n'apparaît pas?

[althio]

Je comprends que ce soit irritant de ne pas voir le résultat sur OpenCycleMap.
Néanmoins, d'autres rendus sont plus actifs et prennent en compte
cycleway:left/right.
Voir OSMAND d'après les retours, ou
http://mijndev.openstreetmap.nl/~ligfietser/fiets/index.html

D'autre part, effectivement, le wiki et les outils d'édition ont pris
pour parti d'inclure ces détails si possible.
Il ne faut pas se laisser dicter le tagging par un rendu - certes
spécialisé - mais pas spécialement maintenu et mis à jour.

Peut-être qu'un jour, OCM sera repris en main ou bien un nouveau rendu
viendra sur le remplacer sur les exemples osm.org / couches.

En attendant, à la limite, on peut dupliquer l'information, si on
tient absolument à tagguer pour le rendu OCM :

highway = *
oneway = yes
cycleway:left/right = opposite_lane
cycleway = opposite_lane

-- althio


2017-06-26 12:31 GMT+02:00 Shohreh <codecompl...@free.fr>:
> Merci pour les infos.
>
> Je vais donc à partir de maintenant utiliser "cycleway=opposite_lane".
>
>
>
> --
> View this message in context: 
> http://gis.19327.n8.nabble.com/OCM-Pourquoi-cycleway-left-opposite-lane-n-apparait-pas-tp5898344p5898371.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Tags pour une petite salle de concerts de jazz

[althio]

2017-05-18 7:52 GMT+02:00 Jean-Christophe Becquet :
>
> Quels tags préférer pour une petite salle de concerts de jazz
> <http://losonsjazzclub.fr> ?
>
> amenity=theatre
> theatre:genre=jazz
> http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtheatre


 Pour un club de jazz, ça semble bien.

-- althio

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

Re: [OSM-talk-fr] [13 mai] journée vélo et outils OSM avec l'association MDB

[althio]

L'association MDB - Mieux se Déplacer à Bicyclette - organise une
journée de formation sur les outils de cartographie (OpenStreetMap et
uMap) le samedi 13 mai au PROTO204 à Bures-sur-Yvette (campus de la
fac d'Orsay).

Inscription, informations et programme mis à jour sur le forum

http://forum.openstreetmap.fr/viewtopic.php?f=18=5331=14925#p15772

2017-03-27 17:24 GMT+02:00 althio <althio.fo...@gmail.com>:
> L'association MDB - Mieux se Déplacer à Bicyclette - va réunir ses
> antennes locales (Île-de-France) en mai et en profiter pour faire une
> journée de formation sur les outils de cartographie (OpenStreetMap et
> uMap).
> Cette journée va se dérouler le samedi 13 mai au PROTO204 à
> Bures-sur-Yvette (campus de la fac d'Orsay).
>
> Informations et programme en cours sur le forum
> http://forum.openstreetmap.fr/viewtopic.php?f=18=5331
>
> Nous recherchons des personnes du type `bicycle=designated`pour
> participer un peu, beaucoup, passionnément, faire des présentations,
> exemples, démonstrations, taguer des revêtements, montrer les
> relations des euro-véloroutes, etc.

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

Re: [OSM-talk-fr] Comment tagguer un cabinet d'infirmières / ers ?

[althio]

Il y a une proposition dans healthcare2.0

http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0/Examples#Office_of_a_nursing_company_or_service

- althio


2017-04-19 12:03 GMT+02:00 pepilepi...@ovh.fr <pepilepi...@ovh.fr>:
> Bonjour,
>
> Tout est dans le titre. J'ai cherché un peu partout dans le wiki, de amenity
> à healthcare, pas moyen de trouver comment indiquer ces braves dames -et de
> plus en plus de messieurs aussi- qui viennent à domicile faire piqûres,
> pansements, prises de sang et autres soins infirmiers.
>
> Comment les noter ?
>
> Merci,
>
> Jean-Pierre
>
>
> ___
> 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] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[althio]

Bonjour,

Comment on avance sur le sujet des landuse=farm à remplacer ?

Après Jungle Bus, il y a un Jungle Farm à développer ?
Ou bien en mode atelier dédié, pendant SotM-France pour attaquer
toutes les idées ? Pour lancer un outil, ou simplement lancer les
modifications ?

> On peut aussi profiter de l'arrivée du RPG (Registre Parcellaire Graphique)
> ...
>> Idéalement il faudrait un outil pour faciliter l'intégration...

>> distinctions corps[farmyard] / champs[farmland]
>> d'ajouter les bâtiments.
>> On peut raffiner la géométrie si c'est du Corine CLC brut.

> aller plus loin en landuse "agricole" :
> landuse=farmland
> landuse=meadow
> landuse=orchard
> landuse=vineyard
> landuse=* ...

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

Re: [OSM-talk-fr] Projet du mois - Panneaux électoraux

[althio]

> J'ajoute actuellement des panneaux électoraux sur Dijon et je me disais
> que c'était bête d'ajouter les panneaux sans les bureaux de vote.
>
> Et j'ai une liste à jour :
> http://www.cote-dor.gouv.fr/IMG/pdf/2017-2018_liste_bv_arrond.dijon_par_cantons_avec_adresses.pdf
>
> Je ne trouve aucune information sur le wiki à ce propos.
> --
> Dlareg

Dans le passé, la discussion s'est déroulé ici :
http://wiki.openstreetmap.org/wiki/Proposed_features/polling_station
ou sur les listes.

- althio

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

Re: [OSM-talk-fr] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[althio]

2017-03-30 1:24 GMT+02:00 Jérôme Amagat <jerome.ama...@gmail.com>:
> les landuse=farm de plus de 2m² donc 2 hectares aussi grand c'est que ça
> a été créer pour représenter des champs et pas un corps de ferme.
> il peut il y avoir des bâtiments au milieu mais c'est en majorité des champs
> donc le tag landuse=farmland convient donc ensuite :
>
> remplacer le tag landuse=farm par landuse=farmland dans toute la sélection
>
> ensuite regarder ce qui reste avec le tag landuse=farm pour voir quoi en
> faire

On n'est pas pressé ;)
On peut prendre le temps de comprendre les tags disponibles, de faire
les distinctions corps[farmyard] / champs[farmland] et d'ajouter les
bâtiments.
On peut raffiner la géométrie si c'est du Corine CLC brut.
...

-- althio

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

Re: [OSM-talk-fr] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[althio]

> JOSM est votre ami : j'ai regardé par chez moi et je suppose qu'ailleurs
> c'est pareil : il n'y avait pas de découpe entre la partie corps de ferme et
> la partie champ (logique : on ne distinguait pas les deux). Donc il va
> falloir découper.

Les tags étaient là mais ils étaient mal compris, d'où des choses à reprendre.
Une bonne image vaut mieux que mille mots pour l'usage basique en landuse
http://wiki.openstreetmap.org/wiki/File:Landuse%3Dfarmyard.jpg

Mais on peut bien sûr aller plus loin en landuse "agricole" :
landuse=farmland
landuse=meadow
landuse=orchard
landuse=vineyard
landuse=* ...


> je ne vois pas trop l'intérêt soit dit en passant : les bâtiments
> d'une zone agricole sont des bâtiments agricoles. En le disant explicitement
> on ne dit pas grand chose de plus.

L'usage de "landuse" et de "building" n'est pas le même (c'est la même
histoire avec les écoles, ...).
Tant qu'on parle de "landuse" :
landuse=farmyard est pour l'espace qui correspond au corps de ferme,
il contient des bâtiments et des zones de travail mais n'est pas un
bâtiment.
landuse=farmland est pour les champs / terres / espaces cultivés...

Quand on passe aux bâtiments :
http://wiki.openstreetmap.org/wiki/Tag:building%3Dfarm
building=farm
building=barn
building=stable
building=sty
building=cowshed
building=farm_auxiliary

-- althio

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

[OSM-talk-fr] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[althio]

Le tag landuse=farm sera bientôt retiré du rendu standard de openstreetmap.org
[openstreetmap-carto sur GitHub
https://github.com/gravitystorm/openstreetmap-carto]

Il est maintenant suggéré de choisir un des tags plus explicites,
typiquement landuse=farmland ou landuse=farmyard ou autre landuse=*
...
Pas d'éditions automatiques bien sûr ! Vous pouvez tomber sur des
reliquats de CLC - Corine Land Cover.

Dans quelques jours les éléments landuse=farm ne seront plus visibles,
les trous dans la carte rendue seront des bonnes indications des zones
à travailler.

Bonnes balades cartographiques à la campagne !

-- althio



-- Forwarded message --
From: nebulon42 <nebulo...@mailbox.org>
Date: 22 March 2017 at 13:56
Subject: [OSM-talk] Upcoming removal of landuse=farm in the standard style
To: osm-talk <t...@openstreetmap.org>, tagg...@openstreetmap.org


Dear all,

at openstreetmap-carto - the standard style on osm.org - a change has
been merged
(https://github.com/gravitystorm/openstreetmap-carto/pull/2554) to drop
rendering of landuse=farm. There was overall consensus that this tag is
deprecated and its usage steadily declined over the last years, but
there are still around 340 000 uses. See
https://taginfo.openstreetmap.org/tags/landuse=farm and
http://taghistory.raifer.tech/ for details.

This change will make it into the next release, but there is no release
date yet. You might want to change cases of landuse=farm in your area to
either landuse=farmland or landuse=farmyard before that. Please don't do
any automatic re-tagging though. After the release empty spots will make
it easier to clean up the remaining uses of this tag.

Michael


___
talk mailing list
t...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk-fr] Tag Aide aux sans-abri et autres

[althio]

Je pense aussi que "Key:social_facility" est la bonne base de départ.

Peut-être qu'il ne faut pas utiliser "amenity=social_facility" car il
ne s'agit pas de la fonction première du lieu.
Les constructions "social_facility=*" et "social_facility:for=*" sont
à mon avis particulièrement adaptées.

http://wiki.openstreetmap.org/wiki/Key:social_facility#Whom_is_served_by_the_facility
social_facility:for=homeless

http://wiki.openstreetmap.org/wiki/Key:social_facility#Different_types_of_social_facilities
social_facility=shelter
Il faut certainement innover pour le reste :
social_facility:phone=yes
social_facility:toilet=yes
...

et puis aussi pour la santé :
http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0#health_service:.2A.3Dyes.2Fno

-- althio

2017-03-24 23:57 GMT+01:00 Philippe Verdy <verd...@wanadoo.fr>:
> Egalement:
>
> Key:social_facility
>
>
> Le 24 mars 2017 à 23:55, Philippe Verdy <verd...@wanadoo.fr> a écrit :
>>
>> A voir avec Key:community centre
>>
>> Le 24 mars 2017 à 23:51, Donat ROBAUX <dona...@gmail.com> a écrit :
>>>
>>> Bonjour,
>>>
>>> Vous le savez peut-être que des initiatives en faveur des SDF se
>>> développent ca et là.
>>> Je pense notamment au café ou baguette suspendu
>>> (http://www.leparisien.fr/espace-premium/air-du-temps/un-cafe-solidaire-s-il-vous-plait-20-04-2013-2742511.php).
>>> Ou encore à l'initiative Le Carillon (http://www.lecarillon.org/le-projet)
>>> qui propose aux commerçants volontaires pour apporter une petite aide aux
>>> SDF de coller une petite affiche sur leur devanture?
>>>
>>> Y a-t-il un tag pour distinguer ses magasins?
>>>
>>> Donat
>>>
>>> Garanti sans virus. www.avast.com
>>>
>>> ___
>>> 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] [13 mai] journée vélo et outils OSM avec l'association MDB

[althio]

L'association MDB - Mieux se Déplacer à Bicyclette - va réunir ses
antennes locales (Île-de-France) en mai et en profiter pour faire une
journée de formation sur les outils de cartographie (OpenStreetMap et
uMap).
Cette journée va se dérouler le samedi 13 mai au PROTO204 à
Bures-sur-Yvette (campus de la fac d'Orsay).

Informations et programme en cours sur le forum
http://forum.openstreetmap.fr/viewtopic.php?f=18=5331

Nous recherchons des personnes du type `bicycle=designated`pour
participer un peu, beaucoup, passionnément, faire des présentations,
exemples, démonstrations, taguer des revêtements, montrer les
relations des euro-véloroutes, etc.

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

Re: [OSM-talk-fr] installation troglodytique

[althio]

Bonjour,

Je suggère d'utiliser le tag existant plus global :
historic=archaeological_site
https://wiki.openstreetmap.org/wiki/FR:Tag:historic%3Darchaeological_site

Pour détailler, il faudrait inventer un sous-tag site_type=*.
Pour coller encore à l'existant (historic=tomb ; tomb=rock-cut), je te propose
historic=archaeological_site
site_type=rock-cut

avec des options pour:
ruins=yes
tourism=yes
name="nom du site"
historic:civilization=*
historic:period=*
historic:era=*
start_date=*
...

Je serai ravi d'avoir ton retour, pour savoir si cela te semble assez
détaillé et correspondre à la situation.

-- althio


2016-12-08 10:12 GMT+01:00 ades_...@orange.fr <ades_...@orange.fr>:
> bonjour,
> comment taguer un habitat ou une installation troglodytique ?
>
> taginfo ne renvoie que des occurrences associées au champ ‘name’.
> ___
> 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] Comment tagguer un magasin de produits frais ?

[althio]

2016-11-18 14:31 GMT+01:00 Francescu GAROBY <windu...@gmail.com>:
> Vu la photo, j'ai l'impression que  chaque commerce est indépendant des
autres : ça n'est pas une épicerie qui fait tout, mais plusieurs petits
commerces de bouche situés dans le même bâtiment, non ?

Non, ce n'est pas ça, c'est une entrée commune, dans un seul magasin.

Et pour moi, le juste tag est...

shop=supermarket

tu peux aussi affiner :
organic=*
...=*

Le seul truc à inventer c'est peut-être un tag
fresh=yes/no/only ?

-- althio


2016-11-18 14:31 GMT+01:00 Francescu GAROBY <windu...@gmail.com>:

> Bonjour,
> Vu la photo, j'ai l'impression que  chaque commerce est indépendant des
> autres : ça n'est pas une épicerie qui fait tout, mais plusieurs petits
> commerces de bouche situés dans le même bâtiment, non ? Si oui, taggue
> chaque magasin séparément, et mets le noms "Grand Frais sur le bâtiment.
> Et s'il y a une vente de fruits et légumes, il te manque alors un
> "shop=greegrocer"
>
> Francescu
>
> Le 18 novembre 2016 à 14:23, Florian LAINEZ <winner...@free.fr> a écrit :
>
>> Bonjour,
>> Un nouveau magasin vient d'ouvrir, il s'appelle "Grand Frais" et il vend
>> des produits frais : fruits et légumes, épicerie, fromagerie, boucherie et
>> poissonnerie cf. sa photo
>> <https://www.mapillary.com/app/user/overflorian?lat=48.825913319946494=1.9678884699968648=17=C4xAMTHUWJtaFr7u7LZcDg=photo>
>> Comment taguer cet OVNI ?
>>
>> Je lui ai mis un tag shop=butcher;bakery;cheese;seafood
>> <http://www.openstreetmap.org/node/4508427980> mais ça ne me satisfait
>> guère. Ce n'est pas non plus un shop=convenience, mais qu'est-ce donc ??
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian <http://twitter.com/overflorian>
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr