Re: [OSM-talk-fr] Plans lignes RER?

2020-03-07 Par sujet marc marc
Le 07.03.20 à 01:52, Shohreh a écrit :
> Shohreh wrote
>> J'ai besoin, pour chaque ligne RER, de trouver le tracé géographique,
>> c.a.d. avec l'IdF en fond de carte, par le plan de ligne administratif
>> type SNCF/RATP.
> 
> Comme j'avais besoin de schémas plus propres que ce que les relations
> remontaient par OverpassTurbo, j'ai cherché sur le Net et fini par trouver
> les fichiers du réseau ferré sur le site d'IDFM :
> 
> https://data.iledefrance-mobilites.fr/explore/?sort=modified=R%C3%A9seau+ferr%C3%A9
> 
> Bizarrement, des KML plutôt que des GPX, et les noms sont en majuscule, donc
> un peu de regex et GpsBabel pour convertir les KML et fusionner les données.

et au final quelle différence ?
un exemple de tracé "pas propre" dans osm et la comparaison avec le
tracé idfm ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Bâtiments d'hôpital autre que lieu soin...

2020-03-04 Par sujet marc marc
Le 05.03.20 à 00:38, Donat ROBAUX a écrit :
> /building=service/ sur tout ce qui est
> technique (services techniques, lingerie, chaufferie,...)

j'espère qu'il n'y a personne qui a son local de travail
dans un building=service (bâtiment genre de ceux qui héberge
un poste transformateur)
building=* l’apparence
building:usage=* l'usage si elle diffère de l'apparence
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Tagguer les Maison du vélo, atelier et asso vélo

2020-03-04 Par sujet marc marc
Le 04.03.20 à 22:08, Florimond Berthoux a écrit :
> - Un atelier associatif de d'auto-réparation de vélo

> Comment tagguer tout ça ?

shop=bicycle_repair
operator:type=ngo
self_service=only ou self_service=assisted ou qlq chose du genre
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [PROPOSITION] [SANTé MENTALE][CMP] amenity=hospital et FINESS

2020-03-03 Par sujet marc marc
Le 03.03.20 à 13:54, Jacques Lavignotte a écrit :
> alt_name=Le nom long du CMP du centre Hospitalier Spécialisé
> name=CMP de Chauvigny

name=Le nom long du CMP du centre Hospitalier Spécialisé
short_name=le nom court
:)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Rendu des social_facility

2020-02-27 Par sujet marc marc
Bonjour,

La page Wiki dit que cela nécessite 
amenity=social_facility

En passant un mot/abréviation générique n'est pas un nom au sens osm

Cordialement,
Marc

Le 27 févr. 2020 à 14:43, Arnaud Champollion 
mailto:arnaud.champoll...@linux-alpes.org>> 
a écrit :


Bonjour,

Il y a quelques semaines j'avais ajouté deux structures d'accueil pour enfants 
: CAMSP et CMPEA.

https://www.openstreetmap.org/node/7124272723

https://www.openstreetmap.org/node/7124272724

avec

social_facility

ambulatory_care
social_facility:for
child

selon :

Services à domicile ou ambulatoires pour handicapés
Service d'éducation spéciale et de soins à domicile (SESSAD), Centre 
médico-psycho-pédagogique (CMPP), Centre d'action médico-sociale précoce 
(CAMSP), Bureau d'aide psychologique universitaire (BAPU). Mettre 
social_facility=ambulatory_care. Selon le cas, ajouter 
social_facility:for=disabled ou 
social_facility:for=mental_health.


Le rendu OSM.org ne les fait pas du tout apparaître, ni le 
rendu Humanitaire.

La recherche par l'outil "nominatim" intégré à osm.org ne 
permet pas non plus de trouver ces services.

(par contre elle trouve le CMPEA d'une ville voisine qui est, pour le coup, 
taggué avec le seul attribut "name").

On ne peut les trouver qu'avec une requête overpass ou en sachant déjà où c'est.


Est-ce que j'ai oublié quelque chose ?

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] Données sur les bouches de métro franciliennes

2020-02-21 Par sujet marc marc
Le 21.02.20 à 20:56, osm.sanspourr...@spamgourmet.com a écrit :
> 
>>
>>> j'ai séparé entrée du métro <> ascenseur, cela devrait être plus
>>> clair.
>>
>> Marc, tu veux dire que tu as deux sorties dont une highway=elevator ?

le coin est.. original
il n'y a pas d'entrée escalier/escalator proche
l'autre entrée de la station n'a pas de ref
mais il y a une flopée de porte sans tag railway=subway_entrance
difficile d'avoir une vue d'ensemble, meme le sélecteur de josm
a du mal à produire une vue d'ensemble
faudrait voir avec un rendu 3d ou indoor :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Relation pour places de parking, quel rôle pour les membres ?

2020-02-21 Par sujet marc marc
Bonjour,

Le 21.02.20 à 21:15, Arnaud Champollion a écrit :
> Donc j'ai mis amenity=parking_space + parking_space=disabled
> Apparemment on peut aussi mettre access=no + disabled=yes mais peut-être
> pas tout en même temps ?

on n'a jamais finit de ce mettre d'accord sur ce point, donc il y a de
mémoire au moins 3 schémas différents

> "La relation type=site peut être utilisée avec site=parking

inutile en surface (et aucun usage connu)
fait toi un polygone amenity=parking c'est bien plus simple/utilisé

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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-21 Par sujet marc marc
Le 21.02.20 à 11:06, osm.sanspourr...@spamgourmet.com a écrit :
> Le 20/02/2020 à 22:07, Sébastien Hinderer a écrit :
>
>> ref a des valeurs bizarres:
>
> ASC : peut-être pour dire qu'il y a un ascenseur ?

j'en ai regardé une, sur laquelle tu avais d'ailleurs fait pas mal
de correction.

j'ai séparé entrée du métro <> ascenseur, cela devrait être plus clair.

vu que c'était pas du vandalisme "Paris Sud", je l'ai déplacé dans ce
thread :) les autres sont surement aussi à passer en revnue.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Parking réservé aux bus touristiques

2020-02-19 Par sujet marc marc
Bonjour,

Le 19.02.20 à 16:35, Vincent Bergeot a écrit :
> il y a souvent des parkings réservés aux bus

aux seuls bus ou aux seuls bus touristique ?
amenity=parking ou amenity=parking_space (selon que tu veux renseigner
que tout le parking est réservé, ou une partie de celui-ci)
access=no
bus=designated si c 'est pour tous les bus
tourist_bus=designated si c'est que les bus touristiques

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


Re: [OSM-talk-fr] Tagguer un restaurant avec buffet à volonté

2020-02-19 Par sujet marc marc
Bonjour,

Le 19.02.20 à 10:57, Francescu GAROBY a écrit :
> La question est dans le titre : comment taggueriez-vous (si tant est que
> cela se taggue) un restaurant qui propose un buffet à volonté ?

il y a eu une discussion un peu semblable sur tagging à propos de l'eau
le mot refill en est sorti, plus précisément drinking_water:refill

vu qu'il y a des resto avec nourriture et/ou boisson à volonté,
quelque chose comme drink:refill=yes/no et cuisine:refill=yes/no ?

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


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

2020-02-19 Par sujet marc marc
Bonjour,

Le 19.02.20 à 02:31, Eda a écrit :
> camera:signed=yes ou camera:signed=no

qu'apporte ce nouveau tag par rapport à ceux existant ?
parce que c'est bien là le soucis actuel : chaque objet a une façon
logique différente d'etre renseignée ce qui par exemple nécessite à
chaque fois des lignes de code spécifique pour les faire adopter dans
iD/Josm ou StreetComplete... sans parler de la mémnoire des
contributeurs pour retenir toutes ces variantes de la même roue.

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


Re: [OSM-talk-fr] Bon usage de tracktype

2020-02-18 Par sujet marc marc
Bonsoir,

Le 18.02.20 à 20:21, Sébastien Dinot a écrit :
> marc marc a écrit :
>> ou pas) en fonction de TA préférence de revêtement pour TON véhicule
> 
> EST-CE QUE L'USAGE DES MAJUSCULES DONNE RAISON AUX GENS ?

non, cela permet juste d'accentuer l'un ou l'autre mot important.
d'autres font du *gras* d'autre un tl;dr;
Avec 2 mots sur la journée (voir peut-être le mois), je n'avais pas
l'impression d'en abuser. si cela t'a choqué, j'espère que tu m'en
excuseras.
D'ailleurs, j'aurais du éviter de cibler un message, car le mien était
générique, j'ai l'impression que l'unique argument sorti et ressorti
pour expliquer de pas faire comme l'usage habituel est "forcer le
routage et/ou le rendu à avoir un résultat pour tous qui respecte
la vision de quelle voie doit être utilisée par tous",
ce que je trouvais un peu irritant comme répétition.

> je faisais une erreur en utilisant le grade1 au lieu du grade2.

je n'ai en rien critiqué le reste, tant mieux pour le changement d'avis.

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


Re: [OSM-talk-fr] Bon usage de tracktype

2020-02-18 Par sujet marc marc
Le 18.02.20 à 15:04, Sébastien Dinot a écrit :
> à partir du moment où l'on choisit d'emprunter une piste plutôt qu'une route, 
> il faut bien s'attendre à avoir une surface moins roulante et plus technique 
> que celle d'une route.

pure supposition qui dépend de ton mode de transport et de la distance

en suisse, à vélo, vaux mieux (en tout cas dans certains régions)
prendre une piste agricole bétonnée (tellement fréquent qu'ils ont un
terme dédié à cela "chemin bétonné" plutôt que de prendre une voie de
transit (où un peux rencontrer un camion de 40T à 80km/h).
Donc j'aprécie fortement la possibilité pour un routage
de favoriser les track grade1 de qualité au lieu des autres.

A l'inverse en voiture, faut prendre les voies de transit
le plus longtemps possible et ne prendre une voie dit de service ou
agricole que pour le dernier morceau (sinon comme le dit l'exemple
précédent, tu pourrais rencontrer des tracteurs ou autre qui vont de
bloquer...
essaye d'imaginer le chargement de rondin de bois avec le camion
sur la  piste, tu comprendras la différence entre transit et non transit

on voit bien que tager l'utilité par type de revetement ne donne rien.
une voie de transit n'est pas une track et inversement.
selon l'usage l'un des 2 conviendra mieux mais faire ce choix (transit
ou pas) en fonction de TA préférence de revêtement pour TON véhicule
ne convient pas, le classement dépend de plusieurs facteur, voilà
pourquoi il y a un tag pour chaque critère et non tout en un tag.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Bon usage de tracktype

2020-02-18 Par sujet marc marc
> Comment tu déclares les voies de desserte agricole et forestière
> goudronnées?

en séparant les 2 :
- classent : highway=track par opposition à highway=unclassified si
c'est une voie de transit inférieur à tertiaire, par opposition aussi à
highway=service pour les voies de non-transit tel que déserte de maison,
déserte de parking
- surface avec le tag surface
éventuellement complété avec la qualité avec le tag smoothness
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Lien pour éditer un objet à partir d'une carte uMap

2020-02-18 Par sujet marc marc
Le 18.02.20 à 12:32, Jean-Christophe Becquet a écrit :
> Le 18/02/2020 12:19, marc marc a écrit :
>> Le 18.02.20 à 12:16, Jean-Christophe Becquet a écrit :
>>> Mais je ne trouve pas comment enchaîner les 2 requêtes dans un même appel.
>>
>> (
>> requête1;
>> requête2;
>> );
> 
> Apparemment, on ne peut pas redéfinir le out entre les 2 :
> 
> http://overpass-turbo.eu/s/QNT

oui il ne faut une déclaration pour toute la requête
et un out suffit, quelque chose du genre
https://overpass-turbo.eu/s/QNV

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


Re: [OSM-talk-fr] Lien pour éditer un objet à partir d'une carte uMap

2020-02-18 Par sujet marc marc
Le 18.02.20 à 12:16, Jean-Christophe Becquet a écrit :
> Mais je ne trouve pas comment enchaîner les 2 requêtes dans un même appel.

(
requête1;
requête2;
);
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Où renseigner name:eu dans le wiki ?

2020-02-18 Par sujet marc marc
Bonjour,

Le 18.02.20 à 12:05, Vincent Bergeot a écrit :
> Comment puis-je retirer cette redirection automatique ?

tu cliques sur "(Redirigé depuis Key:name:eu)" tout en haut de la page
et cela t'amene à la page en désactivant la redirection.
il te suffit ensuite de l'éditer comme d'habitude

PS: je n'ai pas trouvé d'autre name:xx (testé avec name:fr name:ca
name:oc name:de) ayant autre chose qu'une page de redirection.
du coup je suis pas sur de la pertinance de ce que tu veux faire
comparé à traduire la page name elle même en cliquant sur "autre langue,
euskara" depuis la page name.

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


[OSM-talk-fr] Vandalisme utilisateur "PARIS SUD", le retour

2020-02-17 Par sujet marc marc
Bonsoir,

il est de retour, rebanni car revandalisé plein de noms
et autres erreurs comme les fois précédentes.
il serrait utile que chacun prenne un objet dans
http://osmose.openstreetmap.fr/fr/byuser/PARIS%20SUD?level=1
et analyse tout le changeset qui a créé l'anomalie,
en y laissant un mot pour que le contributeur suivant sache que ce
changeset a été traité

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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Par sujet marc marc
Le 17.02.20 à 15:56, Sébastien Hinderer a écrit :
> marc marc (2020/02/17 14:42 +):
>> Le 17.02.20 à 15:13, Sébastien Hinderer a écrit :
>>>> trois stop_area :
>>>>
>>>>  * Place d'Italie (6) (7731239)
>>>><https://www.openstreetmap.org/relation/7731239>
>>>>  * Place d'Italie (5) (7731238)
>>>><https://www.openstreetmap.org/relation/7731238>
>>>>  * Place d'Italie (7) (7731237)
>>>><https://www.openstreetmap.org/relation/7731237>
>>>>
>>>> partageant les mêmes sorties mais pas les mêmes stop_position.
>>> Horreur. On est d'acord que, à gros grains, ces trois noeuds devraient
>>> être supprimés et remplacer par qu nouveau noeud qui les fusionne tous,
>>> n'est-ce pas?
>>
>> hélas non, le métro des lignes 5 6 et 7 ne s'arrête pas au même
>> endroit.
> 
> Mais, ce n'est pas de ça qu'on parle, ici, si je ne m'abuse.
> Là où le métro s'arrête, ce sont les quais, qui sont effectivement
> différents pour chaque ligne et chaque direction. Mais il y a bien une
> entité abstraite, non géographiquement localisée, qui s'appelle Place
> d'Italie et qui est représentée par la relation, je pense. Enfin c'est
> ma compréhension de novice, je ne voudrais pas devenir trop affirmatif.

comme tu parlais de NOEUDS et pas de relation,
je pensais que tu parlais des 3 noeuds stop_position de ces relations
https://www.openstreetmap.org/node/4317624962
https://www.openstreetmap.org/node/4317624965
https://www.openstreetmap.org/node/4317624973

>> par contre, on peux se demander si on a besoin d'un stop_area par ligne
>> ou par station (et un contributeur avait créer encore une nouvelle
>> version de modélisation qui regroupe des stop_area...).
> 
> J'avais peut-être mal compris mais je pensais que stop_area c'était déjà
> les stations, non?

non, la station "logique" est
https://www.openstreetmap.org/node/235371392 (qui a une erreur de tag
par ailleurs)

les relations stop_position sont ambiguës :
pour certains c'est un lien intermodal (pour utiliser cet arrêt,
tu vas à pied à jusqu'à la plateforme d'attente, de là le véhicule te
prendra en charge). c'est en ce sens que le gars a créé 3 relations.

pour d'autres c'est un groupement d'arrêt proches (l'arrêt de la ligne
5 est proche de l’arrêt de la ligne 6 et proche de l’arrêt de la ligne 7
et proche de l’arrêt de bus en surface, donc une relation pour le tout).

> Je suis d'accord. J'ai juste du mal à voir, pour le moemnt, ce qui fait
> unanimité justement et donc ce sur quoi je pourrais avancer.

je donnais 2 dans mon email précédent (à voir si quelqu'un émet
une objection)
- un chiffre n'est pas une nom mais une ref (name=Sortie 1 -> ref=1)
- le nom de la station n'est pas le nom de l'arrêt
et un 3ieme : créer au moins une relation si aucune n'existe
pour cette bouche

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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Par sujet marc marc
Le 17.02.20 à 15:13, Sébastien Hinderer a écrit :
>> trois stop_area :
>>
>>  * Place d'Italie (6) (7731239)
>>
>>  * Place d'Italie (5) (7731238)
>>
>>  * Place d'Italie (7) (7731237)
>>
>>
>> partageant les mêmes sorties mais pas les mêmes stop_position.
> Horreur. On est d'acord que, à gros grains, ces trois noeuds devraient
> être supprimés et remplacer par qu nouveau noeud qui les fusionne tous,
> n'est-ce pas?

hélas non, le métro des lignes 5 6 et 7 ne s'arrête pas au même endroit.

par contre, on peux se demander si on a besoin d'un stop_area par ligne
ou par station (et un contributeur avait créer encore une nouvelle
version de modélisation qui regroupe des stop_area...).
en surface une par arrêt à l'avantage de la simplicité et d'éviter
l'arbitraire de "je décide que cet arrêt là est tellement proche de
celui-là que c'est lié". c'est arbitraire puisque le choix entre
distance à pied et temps de correspondance est variable selon la personne
En souterrain sans les highway=* d'interconnexion des différents zones
d'arrêt, c'est compliqué.

a mon avis, on ne sait pas tout faire en même temps.
se concentrer sur ce qui a une quasi unanimité permet d'avancer,
plutôt que d'attendre la fin d'une modélisation qui n'est pas unique.
hélas..
donc pour ma part je ne change pas l'un envers l'autre.
par contre je crée volontier une relation quand il n'en existe aucune
car je trouve le lien intermodal pratique
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Par sujet marc marc
Merci pour les précieuses réponses précédentes.

Le 17.02.20 à 13:27, Eric SIBERT via Talk-fr a écrit :
> ma recommandation première pour caler les photos satellites est
> d'enregistrer un maximum de trace GPS sur les zones de travail.

je suis mitigé par cette solution.
si je regarde une de mes zones de confort où les images sat ne sont pas
toutes bien alignées (voir toute désalignée), la zone est noyées de
traces mais la qualité de celle-ci étant très variable (y compris
variable au sein même d'une trace), visuellement il n'y a pas grand
chose à en tirer.
il faudrait pouvoir flager une trace en "trop mauvais", ce point là en
"parasité" pour au final garder le potable en vu d'en faire une moyenne.
bref on sauve des centaines de point pour un résultat que je trouve bof.
Ou alors tu as un outil pour trouver la valeur médiane d'un ensemble de
traces ?

comparativement, laisser un enregistreur gps quelque part pour obtenir
une position précise me plaît beaucoup.
en déduire ensuite par différentiel la position précise d'un point bien
identifiable sur imagerie me semble le top. au final un seul point dans
osm et surtout une grande facilité à faire l'alignement, tant pour moi
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

2020-02-17 Par sujet marc marc
Bonjour,

Le 17.02.20 à 12:23, Eric SIBERT via Talk-fr a écrit :
> smartphone
> 10-15 mn, histoire de bien capter un maximum de satellites et de
> récupérer les dernières informations du réseau (satellites en service,

j'avais deja appliqué ce conseil dans le passé pour des photos sur
smartphone.
cependant en prennant des photos de manière "isolée" (une photo
maintenant, une autre photo + tard), j'ai l'impression que les données
récupérées lors du premier long fix ne sont pas sauvegardées.
plus précisément, la 2ieme position met aussi un certains temps à se
stabiliser.
est-ce une impression ? faut-il laisser tourner une appli utilisant
le gps en permanence ? ou certaines applis et ou système sauvegardent
l'information entre 2 utilisations du gps ?

> paramètres de la ionosphère...).

cela est-il pris en compte aussi quand l'appareil est allumé en
intérieur avant de sortir (voiture, veranda) ou cette mesure risque
d'être faussée ?

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


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-17 Par sujet marc marc
Bonjour,

Le 17.02.20 à 11:41, Sébastien Hinderer a écrit :
> où on met le "nom" de la bouche, plus précisément si on le met
> dans name ou dans destination.

> Est-ce que vous croyez que la question peut être tranchée rapidement /
> facilement, histoire de pouvoir avancer sur le sujet?

osm est spécialiste dans les questions pas totalement tranchée :)
si j'étais toi :
- pour la modif des données, je ne toucherais pas pour le moment
à ce point là.
- pour l'utilisation des données, coder un algo qui supporte les 2.

cela te permettrait d'avancer sur tout le reste, principalement :
- le nom de la station n'est pas le nom de la sortie
- un chiffre n'est pas un nom mais la ref
- la relation public_transport=stop_area

pour le cas des sorties escalier+ ascenseur,
je pense qu'il y a 2 façon de le modéliser :
- façon courte avec un objet :
railway=subway_entrance
elevator=yes
wheelchair=yes
- version longue avec 2 objets :
railway=subway_entrance (éventuelement elevator=separate)
highway=elevator

l'iéal étant évidement dans les 2 cas de connecter la bouche
aux highway=* les plus proches.

pour le fait que 2 bouches sont connectés par un réseau interne,
en première approximation, il me sembble pas irréaliste d'ajouter
un highway=* a 2 noeuds qui les connecte, location=underground
en attendant d'avoir une cartographie plus précise (et compliquée)
des réseaux souterrains.

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


Re: [OSM-talk-fr] Les bories, historic ou amenity

2020-02-17 Par sujet marc marc
Bonjour,

Le 17.02.20 à 11:32, Arnaud Champollion a écrit :
> J'aide une contributrice à répertorier les bories, qui sont une des
> appellations, dans le Sud-Est de la France, de cabanes en pierres sèches
> : https://fr.wikipedia.org/wiki/Cabane_en_pierre_s%C3%A8che

quand tu dis "appellation", veux-tu dire que c'est le nom en langage
courant pour désigner n'importe quel cabane en pierres sèches ?
ou c'est un type précis d'abris en pierre sèches par ex architecture
particulière différentes des autres ? le wiki a l'air de dire que c'est
ce dernier cas.

> Sur le Wiki OSM, on trouve une page du projet "Garrigues" qui propose
> une méthode pour les capitelles, un modèle assez proche :
> 
> https://wiki.openstreetmap.org/wiki/Garrigues#Petit_patrimoine_b.C3.A2ti

building:* sans building=* et building:loc spécialité franco-francaise
(voir même ultra local) font mal aux yeux.
si ce n'est plus un bâtiment mais des vestiges historic + description=*
me semble + adapté
si c'est encore un bâtiment ou building=capitelle ou building=shelter
shelter=capitelle
le piège à lapin en building est amusant mais erroné :)

> Je me suis dit qu'on pouvait suivre ce modèle, en adaptant
> building:loc=capitelle-->borie , et en ajoutant description=borie

si c'est une description, pas besoin de la dupliquer dans une autre clef
:) si c'est décrit par une clef, pas besoin de la dupliquer en description.

> historic=shelter
> historic=yes

cela c'est pas possible sur le même objet.
historic=shelter est le plus précis des 2, cela suffit

> shelter_type=basic_hut

si c'est encore aujourd'hui un abris utilisable (par exemple pour
s'abriter d'un orage pendant une balade, alors AJOUT de amenity=shelter
si ce n'est plus actuellement utilisable comme abris, alors il
ce n'est pas cohérent de préciser le type d'abris qu'il n'est pas.
ou alors il faudrait étendre ce cas (que personne ne semble utiliser
hormis l'auteur de la page wiki)

> j'ai modifié historic=shelter en amenity=shelter.

que le résultat soie faux ou juste, ton raisonnement n'a pas de sens.
le tag historic décrit ce que c'était jadis.
le tag amenity décrit l'utilisation actuelle.
l'un est sans rapport avec l'autre (il existe des vestiges d'abris qui
ne sont plus utilisable, il existe des abris actuel qui n'ont rien de
vestiges historiques, il existe des abris qui sont les 2).
c'est pas josm qui doit te guider sur ce qu'est l’objet historiquement
et son utilisable actuelle.

> name=borie

ce n'est pas le nom du bâtiment dans le sens osm de nom.
c'est le mot utilisé pour désigner des milliers d'entre eux.

> soit des historic=archaeological_site

si c'est juste un abris, le décrire comme site archéologique me semble
un peu gros.

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


Re: [OSM-talk-fr] Parking pour véhicules en free floating

2020-02-16 Par sujet marc marc
Le 16.02.20 à 20:59, Florimond Berthoux a écrit :
> bicycle_parking=floor

il y a une discussion sur tagging à propos de l’ambiguïté de cette valeur :
pour certain c'est analogue à parking=surface : cela décrit un parking
extérieur d'un niveau
pour d'autre cela décrit que l'infra se comporte qu'un sol (sans attache).
donc je l'éviterais :)  bicycle_parking=surface me semble + cohérent
avec les parkings voitures, surtout si tu veux renseigner dock sur une
autre clef.
je pense d'ailleurs que toute la problématique parking vélo est pollué
par cette clef double attribut... l'autre solution c'est de mettre les 2
valeurs genre bicycle_parking=surface;dockless

> dockless=designated

pour la clef, je trouve peu pratique les clefs négative.
on finit par avoir dockless=no pour dire qu'il y a des attaches.
donc dock=* me semble préférable. ou lock=* ou qlq chose du genre.

=designated : le sens m'échappe. l'absence d'attache est construite
pour les vélos ?

> motor_vehicle=no

veux tu dire interdit aux mobylettes ?
le reste n'a pas sa place dans la catégorie vélo

> small_electric_vehicle=yes

il y a des parkings qui leur sont interdit ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

2020-02-13 Par sujet marc marc
Bonjour Sébastien,

Le 13.02.20 à 22:29, Sébastien Hinderer a écrit :
> bouches qui n'ont pas de nom. Même parmi celles qui en ont un, le contenu 
> peut varier: soit station, numéro de sortie et nom de la rue, soit juste 
> une partie de ces éléments.

à chaud, sans avoir été chercher la précédente discussion sur le sujet :

le nom de la station n'est pas celui de la sortie, le wiki recommande
l'utilisation d'une relation public_transport=stop_area
pour les lier (et je partage cet avis)

les sorties devraient avoir leur no dans ref=*, j'espère que tout le
monde était d'accord :)

de mémoire (mais je peux me tromper) nous avions surtout discuté du tag
name qui souvent n'est pas vraiment un nom propre à la sortie mais une
destination (pour lequel il existe le tag destination, par exemple
utilisé pour les sorties routières). bien que pertinent comme argument,
je m'en tiens pour l'instant à l'usage documenté (le tag name).

j'avais testé une appli capable d'indiquer le no de sortie le plus court
vers la destination, je ne me souviens hélas plus de son nom.

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


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

2020-02-12 Par sujet marc marc
Le 12.02.20 à 23:02, Victor/tuxayo a écrit :
> Est-ce qu'il aurai a un moyen pour indiquer l'absence de panneau alors
> que c'est légalement requis? (caméra dans un lieu publique en France par
> exemple)

perso je suis fan de l'extention de unsigned sous forme
de  unsigned=
exemple unsigned=addr:housenumber : la plaque du no est absente
sur le terrain (mais l'info est vérifiable en opendata par ex)
donc dans ton cas, quand tu auras trouvé comment renseigner le panneau,
tu auras le moyen de renseigner son absence :-D
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

2020-02-11 Par sujet marc marc
on ets en plein dogme, cfr Réseau Arc en ciel de bus en france

Le 12.02.20 à 00:21, François Lacombe a écrit :
> En corollaire à ces propositions, je pensais suggérer à l'international
> de ne laisser sur la page ref que les références mondiales
> J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
> évidemment les liens vers la page française des références nationales.
> 
> Cela permettra de clarifier les choses entre mondial/national et
> d'inciter les pays à créer leurs propres page et namespace
> 
> Penser qu'il y a aussi un niveau continental, avec quelques entrées en
> Europe par exemple
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
> https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC
> 
> Bonne soirée
> 
> François
> 
> Le mar. 11 févr. 2020 à 23:47, François Lacombe
> mailto:fl.infosrese...@gmail.com>> a écrit :
> 
> Bonsoir à vous
> 
> +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par
> thèmes, comme nous le faisons pour les Map Features ?
> Sur le caractère national/local, pourquoi pas ajouter une colonne
> dans les tables pour le préciser ?
> 
> Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à
> prendre.
> 
> François
> 
> Le mar. 11 févr. 2020 à 18:57, deuzeffe  > a écrit :
> 
> Hello,
> 
> Le 11/02/2020 à 18:25, leni a écrit :
> > Bonjour
> >
> > En attendant que nous trouvions une meilleure solution pour
> certaines
> > ref:FR:*** , je pense qu'il serait bien de partager le tableau
> de la
> > page
> >
> 
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> 
> > (1) en deux parties :
> > - une première partie avec les références qui s'appliquent sur
> > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant
> celles que
> > j'ai trouvées dans le wiki (2)
> > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai
> > trouvées dans le wiki (3)
> > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont
> dans osm
> > et que je n'ai pas trouvées dans le wiki ?
> >
> > Qu'en pensez-vous ?
> 
> Sur le partage, que du bien. Et peut-être "l'ordonner" voire le
> découper
> par thème ?
> Il me semble que j'en avais déjà parlé, sans grand succès...
> 
> -- 
> deuzeffe - qui n'a pas oublié la page transport à toiletter.
> 
> ___
> 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] Nouvelles communes françaises issues de fusion et OSM

2020-02-11 Par sujet marc marc
Le 11.02.20 à 15:16, Rpnpif via Talk-fr a écrit :
> ne pas les repérer par un nœud place=* contrairement aux communes
> d'avant 2010

je pense qu'il y a une erreur de modélisation dans ta vision
place=town/city représente un village/ville, peu importe que la commune
où il se trouve n'ai jamais fusionné ou fusionnée jadis ou récemment.
un polygone ou une relation boundary administrative admin_level=8
représente une commune, peu importe qu'elle ai jamais fusionné ou
fusionnée jadis ou récemment.
il n'y a aucune différence de traitement selon leur origine.

il se fait qu'il y a des villages/villes qui portent le même nom que la
commune et d'autre pas, c'est le choix des intéressés de garder
(fréquent en cas de fusion gros avec petit) ou de changer (fréquent en
cas de fusion entre +- égaux en taille) le nom d'une commune lors de la
fusion.

cela ne va pas du tout de créer un faux place=town/city juste pour faire
apparaître le nom d'une commune parce que invisible sur un rendu donné.
cela ne va pas mieux de créer un lieu-dit inhabité pour forcer
un rendu a afficher le nom d'une commune n'ayant pas de lieu habité
avec le même nom.

si tu veux vraiment créer un objet place=* dupliqué ce serrait
place=municipality qui serrait lui aussi tout aussi invisible par le
rendu que tu critiques (et je partage ton avis sur le côté pas génial
de ne pas voir les communes de manière + claire qu'un nom à la frontière).

une piste de solution : rendre les (toutes) communes + visible sur le
rendu osm-fr pour ensuite en discuter sur le rendu osm-carto
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

2020-02-11 Par sujet marc marc
Le 11.02.20 à 14:00, Florimond Berthoux a écrit :
> 
> 
> Le mar. 11 févr. 2020 à 00:18, marc marc a écrit :
> 
> > donc une alternative et une meilleure manière de le noter est la
> suivante :
> > - traffic_sign=city_limit,FR:EB20.
> 
> je comprend pas ce que tu veux dire avec cette totologie.
> une limite urbaine est un panneau EB20 et vice-versa.
> a-t-on besoin de dire que si on suit le chemin inverse d'une entrée
> c'est une sortie ? cela me semble lourd pour un gain qui m’échappe.
> 
> 
> city_limit c’est FR:EB10 *ou* EB20, le city_limit ne définit pas si
> c’est une entrée ou une sortie
> (oui city_limit est pas top comme tag)

j'ai visiblement mal formulé ma remarque :
FAIT: quand on passe de "hors zone urbaine" à "zone urbaine" en
croissant donc un panneau EB10 dans un sens et un panneau EB20 dans
l'autre sens, cela se MODELISE dans osm par traffic_sign=city_limit
QUESTION : si on modélise l'entrée sur un way bi-directionnel,
a-t-on besoin de dire que dans le sens inverse c'est une sortie ?

On pourrait réserver ce niveau de précision au cas des voie en
sens-unique puisque dans ce cas (seulement ?) le panneau entrée n'est pas
sur le même way que celui de sortie.
Dans les autres (99% ?) cas, c'est une complexification dont
je ne vois l'information supplémentaire qu'elle apporte.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

2020-02-11 Par sujet marc marc
Le 11.02.20 à 14:05, Florimond Berthoux a écrit :
> support=pole
> support:pole:support=ground
> 
> plutôt parce que s’il y a plusieurs support (support=pole;wall) on
> pourra pas préciser le support de quel support.

une photo d'un panneau supporté à la fois par un poteau et un mur ?
j'ai l'impression qu'on est une fois de +  entrain de faire une usine à
gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus
complexe que le cas par défaut. et le contributeur lambda est largé
depuis longtemps par la marche toujours plus grande à entrée...

> Le mar. 11 févr. 2020 à 00:15, marc marc a écrit :
> 
> support=pole : le panneau est porté par un poteau
> support:support=ground : le poteau est directement mis dans le sol

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


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

2020-02-10 Par sujet marc marc
Le 10.02.20 à 23:14, Shohreh a écrit :
> des panneaux qui indiquent qu'une zone est vidéo-surveillée ?

à chaud, j'aurais créé traffic_sign=surveillance
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

2020-02-10 Par sujet marc marc
Bonsoir,

Le 10.02.20 à 21:59, onesim...@free.fr a écrit :
> Je pense qu’on va partir sur des points à proximité de la route, à
> l’emplacement exact du panneau.

je me demande s'il y un logiciel de routage qui l'utilisera

> Il n’est pas possible de mettre 2 fois la même clé par ex. :

si : clef=valeur1;valeur2 (exemple avec la clef cuisine

> donc une alternative et une meilleure manière de le noter est la suivante :
> - traffic_sign=city_limit,FR:EB20.

je comprend pas ce que tu veux dire avec cette totologie.
une limite urbaine est un panneau EB20 et vice-versa.
a-t-on besoin de dire que si on suit le chemin inverse d'une entrée
c'est une sortie ? cela me semble lourd pour un gain qui m’échappe.

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


Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

2020-02-10 Par sujet marc marc
Le 10.02.20 à 22:23, osm.sanspourr...@spamgourmet.com a écrit :
> pour préciser l'ancrage :
> pole_mount=ground ou concrete_slab  à la manière de
> https://wiki.openstreetmap.org/wiki/Key:lamp_mount


lamp_mount est une horreur à ne pas suivre.
support=pole : le panneau est porté par un poteau
support:support=ground : le poteau est directement mis dans le sol
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

2020-02-10 Par sujet marc marc
Le 10.02.20 à 16:00, Jérôme Seigneuret a écrit :
> comment matérialiser la face arrière du panneau qui est sur le même poteau 
> Si l'on fait deux point très proches ce qui fera qu'entre les deux
> points on aura 1 mètre hors agglomération?

simplifie toi la vie :-)
2 points soit exactement au même endroit
soit séparé de 1mm (vu que iD par exemple rend très compliqué
la sélection d'un objet précis parmis plusieurs superposés)

OU

traffic_sign:backward=city_limit
traffic_sign:forward=city_limit
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

2020-02-10 Par sujet marc marc
Le 10.02.20 à 12:30, leni a écrit :
> https://wiki.openstreetmap.org/wiki/Tag:traffic_sign%3Dcity_limit :
> 
> direction=* should be specified. The traffic sign should be faced when
> you drive into the city.
> 
> on ne regarde que le sens du tronçon qui va vers la commune

bien vu... ce serrait à tester si les apps s'en sorte lorsque les 2 way
ont une direction opposée.

>> On reste à la merci d'un contributeur qui retournerait ultérieurement
>> le(s) way(s) pour une raison ou une autre (aménagement latéral
>> disymétrique...) et qui n'aurait pas conscience de l'impact sur les
>> panneaux entré/sortie.

tu as constaté ce cas ? si oui tu te souviens de sa localisation ?
c'est le genre de chose qu'il faut remonter aux éditeurs, c'est pas à
l'humain de passer en revue tous les noeuds d'un way pour les inverse.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

2020-02-10 Par sujet marc marc
Le 10.02.20 à 12:29, Stéphane Péneau a écrit :
> - Christian indique qu'il l'utilise

j'ai beau relire le message de Christian à propos du rendu fr [1],
je ne sais toujours pas qu'est ce qu'il disait d'autre que "le rendu fr
l'utilise"
- était-ce juste une information neutre ? c'est ce qu’apparemment la
majorité à compris (comme dire "j'ai un rendu des bâtiments ne dit rien
s'il faut garder ou supprimer des bâtiments fantaisistes)
- est-ce une demande de temps pour analyser + en profondeur ?
- est-ce favorable à la suppression des données erronées afin
d'augmenter en qualité ?
- est-ce favorable à garder des données parfois fausses d'un facteur 3
parce que le rendu est + joli que sans la donnée ?
un peu comme une façon de faire des place=* intermédiaire

bref, on a foiré mais + sur la comm que sur le fond.
et sur le fond, on fait quoi ? comment sortir par le haut ?
- dupliquer la population communale sur l'unique place=* habité d'une
commune me parait (bof) mais réaliste si on confie la tâche
à un bot (et d'inévitable temps humain pour traiter les anomalies
détectées par osmose)
- pour les communes multi place=* habités, les catégories actuelles ne
suffisent pas à détecter l'écart ? sinon il n'y a pas de source
pour mettre une valeur permettant de les départager ?
- un exemple de rendu avant/après pour montrer un exemple réel ?
ou c'est juste un problème théorique ?

[1]
https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096266.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

2020-02-09 Par sujet marc marc
Le 09.02.20 à 18:59, Christian Quest a écrit :
> Le 09/02/2020 à 18:34, Stéphane Péneau a écrit :
>> Je vois des discussions et des changesets avec des suppressions du tag
>> "population" sur le node "admin_centre"
>>
> J'avoue que ces changements massifs, nationaux, 
> précipités ne me plaisent guère.

c'était p'tre précipité sur les détails (formulation de la source et de
la date)
cela aurait mérité d'être diviser en 2 pour traiter séparement les 2
(maj de la population communale <> erreur d'objet sur le place=*)
mais garder une commune de X habitants avec plus d'un place=* de X
c'est loin d'être une bonne chose
mais tu met 3 semaines à réagir, cela n'aide pas non plus
https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096261.html

Marc qui doit encore faire son édition de masse qui n'a pas reçu
d'objection depuis de nombreux mois.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Équitation et attributs proposés

2020-02-08 Par sujet marc marc
Le 08.02.20 à 13:21, Arnaud Champollion a écrit :
> beaucoup d'attributs "proposés" mais pas validés.
> 
> Est-ce que ça veut dire que pour l'instant on ne les utilise pas ?

dans osm, tout le monde est libre d'utiliser n'importe quel tags.
un tag validé est simplement un tag qui a fait l'objet d'une discussion
au niveau mondial et qui au moment du vote a paru être de qualité.
c'est totalement indépendent d'être présent ou pas dans la bdd,
être ou pas utilisé par le rendu par défaut ou par n'importe quel autre
rendu ou par une application
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] stabilité et stat sur la disponibilité du fond OSM org

2020-02-07 Par sujet marc marc
stable selon ta définition : je me souviens pas quand osm.org
m'a répondu "service pas dispo" ou n'a pas répondu, donc 100% ? :)

disponibilité sans latence : là est le soucis avec osm.org
c'est un choix que d'essayer de faire du rendu "temps réel"
au lieu de répondre avec l'ancienne tuile par défaut.
Et quand la tuile n'est pas dispo sur le serveur de rendu,
la latence pour l'avoir peux être énorme en journée.
sur le rendu libre cyclo hébergé sur osm-fr, le choix inverse a été fait
(fournir la tuile du cache, les maj se font de manière séparé)

le cache du cache d'osm.org : pq pas... pour un petit truc mini...
mais de quelle volunme on parle ?
osm.org est une vitrine et un feedback aux contributeurs,
pas un service commercial gratuit.
Je suis sur qu'il y a des entreprises qui font moins cher que GM
et si tu trouves pas, je te montre la voie :-)

Le 07.02.20 à 17:09, Jérôme Seigneuret a écrit :
> Stable : disponibilité du service sans rupture de continuité
> Disponibilité : accès au service sans latence
> 
> Le cache c'est une des proposition que j'ai proposé pour éviter de
> solliciter inutilement le serveur.
> La tuile à jour oui au démarrage des outils. Ce sont des application
> mobiles. Les délais de réponse c'est du classique mais quelque chose qui
> permet de bosser sans latence visible.
> Le prestataire nous propose du google maps car juge le service
> d'OSM instable... Je cherche donc des contre arguments tangibles et des
> infos sur la rupture de service... Un peu comme on a sur les serveurs
> avec des taux de disponibilité. Je pense que le prestaire par du service
> général osm.org <http://osm.org>. L'autre chose que j'ai proposé c'est
> de monter un serveur miroir pour fournir de la disponibilité avec un
> load balancer. Mais là il y a une question de coût à aborder. De
> toute-façon l'étude de côut GM n'est pas évaluée car compliqué à estimer
> par le prestataire...
> 
> 
> Le ven. 7 févr. 2020 à 16:07, marc marc a écrit :
> 
> Le 07.02.20 à 15:44, Jérôme Seigneuret a écrit :
> > Bonjour,
> >
> > A t'on des stat sur la stabilité et la disponibilité du fond OSM merci
> 
> il y a tellement de critère que cela me semble compliqué.
> c'est quoi stable ?
> c'est quoi disponible ? fournir la tuile en cache c'est disponbile ?
> ou faut fournir une tuile à jour avec les données de moins de X min ?
> répondre en moins de x ms pour les tuiles à jour ?
> 
> côté osm-fr je crois qu'on a aucune stats de ce genre,
> hormis celle qu'on peux sortir du graphe munin (% de tuile servie
> périmée depuis le cache faute d'avoir pu être rendue dans un délais
> court). stats complètement déformée par la présence d'un cache frontal
> et du cache des navigateurs.
> 
> osm.org <http://osm.org> a les mêmes graphes munin, avec les mêmes
> défauts.
> je veux bien me renseigner si les caches distribués ont un monitoring
> qualité style délais pour founir une tuile. mais j'en doute.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto: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] Demande d'intervention de tiers sur un conflit d'édition

2020-02-07 Par sujet marc marc
Le 07.02.20 à 15:49, Charles MILLET a écrit :
> J'ai à nouveau un problème de conflit d'édition avec l'utilisateur
> Meersbrook. cf. https://www.openstreetmap.org/changeset/79878637

je trouve qu'il y a plusieurs problèmes différents :

- un problème humain tant pour suivre la discussion que les arguments :)
poster des liens améliorent facilement la compréhension de ce dont on
parle. laisser la porte ouverte à l'autre pour qu'il s'explique est
aussi plus agréable que de dire "tu as faux" (sinon c'est pas une
discussion). exemple
"ce way là était avant A (panneau présent au début du way) et a été
modifié en B, pourquoi est-ce que cela décrit-il mieux la situation ?
le panneau a-t-il été supprimé ? des travaux ont supprimé la bordure ?"

- la modification de highway=cycleway séparé en cycleway=track est
clairement erronée selon moi.

mon raisonnement :
1) combien de way ?
il y a une séparation physique à droite de la bande voiture de droite.
donc ce qui se trouve de l'autre côté mérite un autre way OU
se décrit avec cycleway=track
pour moi les 2 sont totalement valide, ils représente la même chose.
c'est d'ailleurs la 2ieme ligne de la page anglaise
https://wiki.openstreetmap.org/wiki/Tag%3Acycleway%3Dtrack
l'un est la version simple (cycleway=track) l'autre la version plus
précise (2 way). il n'y a aucune faute à utiliser l'un ou l'autre.
c'est une amélioration de passer du simple au détaillé.
il y a par contre une dégradation inutile donc erroné de faire l'inverse

2)  la bordure du trottoir pour moi n'est pas un obstacle à la
navigation parce que cela concerne le piéton, cela ne l’empêche pas de
traverser en plein milieu d'une rue longue en l'absence de passage
piéton proche) donc j'aurais fais 1 way avec vélo+piéton

3) quelle valeur pour ce way à usage mixte ? et éternel débat entre "je
suis cycliste ou je suis piéton", pour être neutre, j'utilise path

au final vu que le way détaille existe et que sa présence est justifié
un way highway=primary cycleway=separated sidewalk=separated ou
équivalent ou plus précis (:rigth  etc)
un way highway=path foot=designated bicycle=designated segregated=yes

4) guerre d'édition :
annuler l'annulation d'une annulation n'a pas de sens.
quand on en arrive là, il faut demander à l'autre de temporiser.
la modif n'est pas grave pour l'utilisation des données donc
on peux prendre une semaine a discuter calmement sans guerre.

5) en passant le oneway sur un footway est ambigu voir erroné
https://www.openstreetmap.org/way/756596349 version 6
le piéton ne peux pas marcher dans l'autre sens ?
(mapillary rame trop que pour le chercher en ce moment)

si la modification concerne autre chose, je l'ai raté :)
j'attends vos retours avant de poster sur le changeset pour être sur de
n'avoir rien raté qui aurait pu changer mon avis :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] stabilité et stat sur la disponibilité du fond OSM org

2020-02-07 Par sujet marc marc
Le 07.02.20 à 15:44, Jérôme Seigneuret a écrit :
> Bonjour,
> 
> A t'on des stat sur la stabilité et la disponibilité du fond OSM merci

il y a tellement de critère que cela me semble compliqué.
c'est quoi stable ?
c'est quoi disponible ? fournir la tuile en cache c'est disponbile ?
ou faut fournir une tuile à jour avec les données de moins de X min ?
répondre en moins de x ms pour les tuiles à jour ?

côté osm-fr je crois qu'on a aucune stats de ce genre,
hormis celle qu'on peux sortir du graphe munin (% de tuile servie
périmée depuis le cache faute d'avoir pu être rendue dans un délais
court). stats complètement déformée par la présence d'un cache frontal
et du cache des navigateurs.

osm.org a les mêmes graphes munin, avec les mêmes défauts.
je veux bien me renseigner si les caches distribués ont un monitoring
qualité style délais pour founir une tuile. mais j'en doute.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Demande d'intervention de tiers sur un conflit d'édition

2020-02-07 Par sujet marc marc
Le 07.02.20 à 15:49, Charles MILLET a écrit :
> Pour info cette "piste cyclable" est utilisable par les piétons et donc
> nécessite un way séparé et la précision du segregated=yes

il y a une erreur dans l'argument ?
photo classique récente du lieu ou uniquement vue sat ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Termes de licence pour rendre une imagerie compatible avec la création de données dans OSM ?

2020-02-07 Par sujet marc marc
Le jeu. 6 févr. 2020 à 15:52, severin.menard a écrit :
> Existerait-il des licences génériques qui seraient adaptées

cela peux être aussi simple que "je soussigné 
agissant pour le compte de 
déclare mettre à disposition de la communauté openstreetmap l'imagerie
XYZ dont nous disposition les droits (ou dont nous sommes propriétaires)
afin de leur permettre de contribuer à leur projet".

en quelque sorte, tu prend la convention IGN et tu supprimes 99%
pour garder la ligne essentielle :)

pour être transparent, tu colles l'email reçu (pas besoin de papier,
de recommandé, de cachet, sauf si cela te rassure ou s'ils ont envie)
sur une page du wiki nommée en fonction de la couche et/ou de l'entité
et on l'ajoute dans eli et josm :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Étiquette de population pour les nœuds en France villes / villages / villages

2020-02-06 Par sujet marc marc
Bonjour/hello Clinton,

Le 06.02.20 à 14:26, Clinton Mercieca a écrit :
> Is there any particular reason for this

in english : info was wrong (the population from INSEE are for the
municipality, not for cities/towns/villages) and outdated (the source
update its data)
en français : L'information était erronée (la population de l'INSEE est
pour la commune, pas pour les villes/villes/villages) et périmées (la
source a mis à jour ses données)

> A fellow user on the Help forum suggested that this may be related to
> the post below:
> https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096261.html

in english : yes it's related but in fact updating population for
municipality may have been done in a separated changeset than deleting
wrong population tag for cities/towns/villages.
en français : oui c'est lié mais a mise à jour de la population pour la
commune peut être fait dans un ensemble de changements séparés que la
suppression du tag population= erroné des villes/villes/villages.

> Should the population tags at Node level still be retained

in english : why not, but with witch source ?
the previous data was put on the wrong object.
keep wrond value only to have a value is a bad idea.
en français : pourquoi pas, mais avec quelle source ?
les données précédentes ont été placées sur le mauvais objet.
garder une valeur fictive uniquement pour avoir une valeur est une
mauvaise idée.

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


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

2020-02-06 Par sujet marc marc
Le 06.02.20 à 14:22, Alain Rpnpif via Talk-fr a écrit :
> Le 05/02/2020 à 07:20, Vincent de Château-Thierry a écrit :
>> Bonjour,
> 
> 
> Bonjour Vincent,
> 
> Il semble que quelqu'un conteste tes mises à jour ou plutôt ne les as
> pas comprises. C'est sur :
> 
> https://forum.openstreetmap.org/viewtopic.php?id=68546

la personne a écrit à talk-fr-owner en anglais.
on lui a répondu et expliqué, en attente de savoir pq c'était un message
privé (erreur ou volontaire)
mais on pourra copier/coller la réponse sur le forum histoire que le
prochain qui se pose la question retrouve l'info
(vive les éditions de masse documentée... au moins les gens retrouvent
l'info)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Référencer la production alimentaire locale

2020-02-06 Par sujet marc marc
ni plus ni moins que l'ensemble des noeuds d'une frontière administrative :)

Le 06.02.20 à 13:42, Florimond Berthoux a écrit :
> Salut,
> 
> C’est vérifiable sur le terrain ?
> 
> Le mer. 5 févr. 2020 à 19:36, Vincent Bergeot  > a écrit :
> 
> Bonjour,
> 
> pour référencer les lieux de productions alimentaires (les fermes en
> particulier) et pour pouvoir "comparer" avec d'autres listes, j'aimerai
> bien ajouter la ref siret, mais sur quel objet ?
> 
> Quand il y a un lieu de vente le shop=farm semble approprié (à voir si
> il n'y a pas 2 siret différents,à creuser).
> 
> Mais quand il n'y a pas de lieu de vente !
> 
> Sur le farmyard ?
> https://wiki.openstreetmap.org/wiki/FR:Tag:landuse%3Dfarmyard
> 
> place=farm ne semble pas vraiment correspondre
> (https://wiki.openstreetmap.org/wiki/Tag:place%3Dfarm)
> 
> Une idée, suggestion ? ou plusieurs :)
> 
> Bonne fin de journée
> 
> VincentB
> 
> 
> 
> ___
> 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] Interrogation base FINESS

2020-02-05 Par sujet marc marc
Le 06.02.20 à 00:15, deuzeffe a écrit :
> http://finess.sante.gouv.fr/fininter/jsp/index.jsp
> 
> Merci pour vos tests !
> 
test ok :) FF esr centos :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] zone résidentielle dans une zone résidentielle ?

2020-02-05 Par sujet marc marc
Bonjour,

Le 05.02.20 à 19:53, Arnaud Champollion a écrit :
> Est-ce qu'on peut avoir un landuse=residential à l'intérieur d'un autre
> landuse=residential englobant ?

c'est pas interdit mais le 2ieme n'apporte souvent rien de correct
par rapport au 1er. je dirais même qu'un landuse dans un landuse (hormis
les faux landuse comme les pelouses) est souvent le critère parfait
d'une erreur de tag sur l'un des 2

> Par exemple pour un quartier ou un lotissement, comme celui-ci :
> https://www.openstreetmap.org/way/570993621

pq ne pas le tager comme quartier ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Référencer la production alimentaire locale

2020-02-05 Par sujet marc marc
Le 05.02.20 à 19:35, Vincent Bergeot a écrit :
> j'aimerai bien ajouter la ref siret, mais sur quel objet ?

sur l'objet décrit par le siret :)
un office=company ou landuse=farmyard me semble bien
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Miniature fond OSM et lien vers gg Maps

2020-02-03 Par sujet marc marc
Le 03.02.20 à 20:03, deuzeffe a écrit :
>> Que dire... :/

leur dire de basculer vers osm ? :D
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?

2020-02-03 Par sujet marc marc
Le 03.02.20 à 03:23, Francois Gouget a écrit :
> * http://openbittorrent.com/
>   -> Je me retrouve automatiquement sur https://openbittorrent.com/ dont 
>  le certificat est valide pour *.opentrackr.org et pas 
>  openbittorrent.com. Bon, en fait c'est la faute de Https Everywhere 
>  mais il y a quand même un problème avec le certificat.

oui et non :)
rien n'impose d'avoir une version https d'un site annoncé en http
mais *SI* le site a changé d'url, la façon propre est de faire un
redirect de l'ancien nom vers le nouveau nom (et conserver un certificat
https valide si l'ancien nom était dispo en https).

en passant pour moi la vrai erreur, c'est Https Everywhere qui ne
devrait pas basculer en https si le certificat n'est pas bon.
chez moi il ne bascule pas, tu ne l'aurais pas forcé en https ?

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


Re: [OSM-talk-fr] Lavoirs avec eau potable

2020-02-02 Par sujet marc marc
Le 02.02.20 à 14:07, Arnaud Champollion a écrit :
> water=yes , mais ça ne dit pas si l'eau est potable.

drinking_water=yes :)
rien n'empêche de faire 2 objets :
un polygone amenity=lavoir
un point dans celui-ci pour l'eau potable
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Import massif dans OSM des panneaux publicitaires de la Métropole de Lyon

2020-02-02 Par sujet marc marc
ce sont 2 questions séparéees :)
avoir conflate qui fait le taf, ne te met pas à l'abri de quelqu'un
qui estimerait que 2700 objets dans une aglo est un import.
autant une 100aine d'objets, bah, ca passe.
autant pour des milliers, franchement autant faire les choses bien.
surtout qu'avant cela, ce ne serrait pas du luxe de passer les tags en
revue (je dis cela en venant de voir un mapcontrib... améliorable)

Le 02.02.20 à 14:11, Cédric Frayssinet a écrit :
> 
> Merci pour vos différentes réponses. Il semble donc que conflate puisse
> faire le taf' correctement, sans nécessairement avertir la liste import :)
> 
> Je vais me rapprocher des experts JOSM lyonnais !
> 
> Cédric
> 
> 
> 
> Le 01/02/2020 à 11:35, Vincent Bergeot a écrit :
>> Le 01/02/2020 à 11:11, Christian Quest a écrit :
>>> Le 01/02/2020 à 11:03, marc marc a écrit :
>>>> Bonjour,
>>>>
>>>> Le 01.02.20 à 10:11, Cédric Frayssinet a écrit :
>>>>> Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
>>>>> tout en n'écrasant par les différents POI qui pourraient exister.
>>>> de combien d'objet parle-t-on environ ?
>>>
>>>
>>> Quelques centaines à ce que j'ai rapidement vu... pas de quoi
>>> déballer la grosse artillerie ou réveiller les troll de la liste
>>> imports ;)
>>
>>
>> 2700 objets si qgis compte bien
>>
>>>
>>> 1) Vérifier la qualité en comparant avec l'existant, et aussi en
>>> comparant un peu avec le terrain.
>>
>> c'était l'idée avec osmose, car cela peut permettre de comparer et
>> comme ce travail dans osm a été mené dans plusieurs villes, cela
>> pourrait "s'étendre"plus facilement !
>>
>>
>>>
>>> Ceci peut éventuellement l'occasion de faire une cartopartie thématique.
>>
>> +1, j'ai l'impression que les RAP sont bien partants et motivés en
>> plus ! (d'ailleurs Cédric, tu pourrais me mettre en lien avec une
>> personne sur Bordeaux ? par de réponse par leur page de contact !)
>>
>>>
>>> 2) Un bon coup de conflate dans JOSM
>>
>> oui, peut permettre d'aller plus vite
>>
>> oserai-je dire que la question de la ref est à poser ?
>>
>> à plus
>>
>>
> 
> -- 
> 
> Sur Mastodon : @bristow...@framapiaf.org <https://framapiaf.org/@Bristow_69>
> 
> 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


[OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

2020-02-01 Par sujet marc marc
Bonjour,

maj du rendu par défaut d'osm.org
Il n'est pas encore déployé et quand il le sera,
cela prendre comme d'habitude un peu de temps
pour tout mettre à jour.

J'ai retenu ci-dessous les points les plus important :

* Suppression du rendu de barrier=embankment (#4010)
Les remblais sont désormais communément étiquetés avec
man_made=embankment ou man_made=dyke

* Supprimer le rendu de barrier=kerb (#3969)
 Cette caractéristique n'est pas similaire aux barrières courantes
(clôtures et murs)

* Suppression de la couleur de remplissage boundary=protected_area à bas
niveau de zoom (#3887)

* Supprimer le rendu de remplissage des polygones pour les zones de
barrier=hedge (#3844)
 Cela rend le rendu cohérent entre les murs et les haies en tant que
zones

* Enlever l'étiquette de texte de l'opérateur pour la plupart des
amenity=vending_machine (#3965)
L'étiquette Operator= est toujours affichée pour les tickets de
transport public vending=public_transport

* Ajouter l'icône svg pour parking=multi-storey +
amenity=parking_entrance (#3599)


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


Re: [OSM-talk-fr] Import massif dans OSM des panneaux publicitaires de la Métropole de Lyon

2020-02-01 Par sujet marc marc
Bonjour,

Le 01.02.20 à 10:11, Cédric Frayssinet a écrit :
> Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
> tout en n'écrasant par les différents POI qui pourraient exister.

de combien d'objet parle-t-on environ ?

> Question 1 : est-ce faisable ?

oui.
il y 2 pistes :
- soit josm avec l'outil conflate. il permet de rapprocher des objets
présent dans une source externe de ceux existant dans osm selon des
critères et la distance.
- soit il faut un outil plus spécialisé. certains ici en ont écrit pour
l'import d'arbres. il y a aussi celui de Zverik + prévu pour qu'un
groupe passe en revue les données avec l'aide de l'imagerie (mais
ce n'est adapté que si on voit les gros panneaux sur l'imagerie).

avant tout import proprement dit, il faut :
- vérifier la qualité de positionnement de l'opendata en comparant
les objets existant dans osm et ceux correspondant en opendata.
le plugin josm conflate le permet. il permettra d'avoir facilement
une idée de la qualité (distance osm<>opendata)
- il faudra obtenir l'accord de la communauté locale (ici cela
convient sans doute aussi) et de la liste import.
pour ce derrnier point, je te conseille de ne le faire que
quand tout est tip-top (tag passé en revue, accord local,
test de qualité, ...) parce qu'il y a des champions des cheveux coupés
en 4 là-bas, alors autant ne pas leur donner des raisons de critiquer :)

> Question 2 : qui aurait une expertise là dessus pour nous aider ?

avec conflate oui (même si j'utilise souvent les valeurs par défaut)
avec d'autres outils : d'autres plus d'expérience que moi là dessus.

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


Re: [OSM-talk-fr] highway = crossing + footway = crossing VS highway = footway + footway = crossing

2020-01-31 Par sujet marc marc
Le 31.01.20 à 12:32, Mathias Vadot a écrit :

> Je cherche a taguer un passage piéton type zebra avec des picto vélo.

les 2 peuvent coexister :
- le croissement, cad le point d'intersection entre 2 voies :
highway=crossing + crossing=traffic_signals/uncontrolled (présente ou
absence de feu) + crossing_ref = zebra (+ bicycle = yes si cela t'amuse
mais c'est generalement le type de voie qui le renseigne)
- les voies de cheminement, cela côté piéton vélo par ex highway=path +
path=crossing + segregated=yes/no + éventuellement crossing_ref=zebra
sur la partie zebré (mais c'est quand même du sacré micro-mapping).

Mais certains "piétons envahi par les vélos" favorisent highway=footway
+ footway=crossing
tandis que certains "cycliste envahi par les piétons" favorisent highway
=cycleway+cycleway=crossing
ces 2 dernières solutions sont selon moi tous les 2 fausses, sauf
panneau bleu correspondant disant "l'autre aussi".
mais il y a d'autre qui pensent qu'un "path" est exclusivement pour un
cheminement dans un nature. je n'en fais pas partie :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Overpass et dates

2020-01-30 Par sujet marc marc
Le 30.01.20 à 13:20, Cédric Frayssinet a écrit :
> Bonjour à tous,
> 
> Je voulais savoir si on pouvait spécifier, dans OverPass, un intervalle
> de temps avec un compte (actuellement j'utilise 'user' combiné à 'newer').
> 
> En effet, j'utilise qu'un seul compte avec mes élèves, et quand je sors
> pour une cartopartie, je ne voudrai récupérer uniquement les
> contributions de cette sortie.
> 
> À moins qu'il existe une astuce ?

c'est quoi qui ne va pas ? partage le lien :)
à la volée : nwr(user) puis changed:
https://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Par_date_de_changement_.28changed:.29

attention que tu ne récupéreras pas ce qui a été
corrigé/modifié/amélioré par un autre utilisateur entre la sortie et
ta requête  
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Commune (“admin_level”=“8”) sans attribut “postal_code”

2020-01-28 Par sujet marc marc
Le 28.01.20 à 18:03, Jacques Lavignotte a écrit :
> j'ai un doute sur la validité de « postal_code=86130;86490 »

non ce ne serrait pas juste (les addr de la commune n'ont pas chacun 2 CP)
une piste de solution est de mettre le CP le + courant sur la relation
de la commune et faire une 2ieme relation postal_code pour l'étendue de
l'autre CP
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?

2020-01-26 Par sujet marc marc
Le 26.01.20 à 20:09, Christian Quest a écrit :
> Je viens de regénérer des torrents pour le fichier planet pbf:
> http://osm.cquest.org/torrents/

créer autant de torrent mono-seed initial que de personne ayant l'idée
d'héberger un planet en réduit l'intérêt. surtout combiné à la non
priorisation des sources proches.
c'est p'tre cela qui explique la non utilisation, faudrait au moins
avoir le lien depuis la page osm.fr en attend plus communautaire.

ton planet vient d'osm.org ou c'est une génération locale ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Héberger un mirroir ou un bittorrent pour les planet, possible?

2020-01-26 Par sujet marc marc
Le 26.01.20 à 15:27, Thomas Gratier a écrit :
> La version courte: l'ensemble de la communauté en récupérant des planet
> complets finit par saturer la bande passante

question courte (de la discussion qui a lieu aussi sur la ml dev) :
pq 100 personnes ont besoin chaque semaine de télécharger le planet ?
je crois que certains ignorent ou trouvent trop compliqué la maj
cela implique de mieux informer et/ou rendre la maj + facile.

> OpenStreetMap France pourrait créer un miroir et/ou une version torrent?

l'ironie c'est que pour le moment, faire un miroir doit se faire
par téléchargement d'un planet toute les semaine.
le planet osm.org lui meme n'est pas produit avec les diff.
après rien n'interdit de produire un planet non mirroir de l'original.
cela dépend de la réponse à la question précédente.

> Un/des avis?

une piste est de comprendre le besoin (voir point 1)
une piste est la création d'un planet non miroir (voir point précédent)
une piste est la création d'un miroir à la volée : pas de dl automatique
entre osm.org et osm.fr chaque semaine mais si qlq clique sur le lien
osm.fr, cela télécharger le dernier planet osm.org et le met à
disposition pendant une semaine (puisqu'après il est "périmé")
ainsi si 2 personnes téléchargent le planet via osm.fr
il y a un gain, sans jamais provoquer de trafic inutile.
la piste d'un miroir osm.org me semble venir après même si perso je
serrai pour, surtout si geolimité pour favoriser l'efficacité (car il y
a deja un outil qui télécharge sur tous les miroirs en meme temps,
c'est très con de télécharger sur un miroir loin quand on en a un proche)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Avec quoi taguer une résidence pour étudiants ?

2020-01-26 Par sujet marc marc


> Le 26 janv. 2020 à 18:35, Brice  a écrit :
> 
> Des idées ?

building=l'apparence (un gros bloc dormoir est une dès apparence possible)
Building:use=residential
Éventuellement qlq genre for=student ou student=designated 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Motorroad sur Trunk en France

2020-01-25 Par sujet marc marc
Le 25.01.20 à 23:03, Florimond Berthoux a écrit :
> mais je vois

moi je vois pas les panneaux sur les 2 premiers qui sont la base de la
classification en fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] couche cadastre [était : Afficher un flux WMS de l'ONF dans JOSM]

2020-01-25 Par sujet marc marc
Le 25.01.20 à 18:36, deuzeffe a écrit :
> pour la couche cadastre (par ex.), qui est donc en LO, on indique quand
> même nom, source et millésime, non ?

on a 3 outils différents et 3 source=* différentes dans le texte.
pas génial pour les outils qui veulent retrouver l'info
en plus, source=... 2019 ne dit pas que cela a été fait avec la source
en 2019 parce que le gars (moi et d'autres) qui s'occupent de faire la
maj ne le font pas nécessairement au passage de l'an... et meme si c'est
fait ce jour c'est pas nécessairement publié ce jour... et meme si c'est
publié c'est pas nécessairement re-télécharger ce jour..

alors ce serrait p'tre plus que temps de passer à des données simple
et à jour : source=cadastre sur le changet date : celle du changeset
au moins on aurait plus de source définie sur une date alors que la
géométrie a changé entre temps...

à défaut source=casatre AAA serrait deja un petit pas en avant
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

2020-01-25 Par sujet marc marc
Le 25.01.20 à 21:07, Romain MEHUT a écrit :
> Qu'en pensez-vous ?

il a fait un doublon, ta remarque est justifiée qu'il faut mettre à jour
l'objet existant.

il aurait du répondre avant de continuer avec des nouveaux objets,
tout a fait d'accord aussi.

en meme temps cela fait que 2 jours et résoudre l'erreur serra facile.
mais si tu veux, demande un 0-hour ban (un blocage qui oblige
l'utilisateur à lire le message, il peux continuer ensuite...
s'il le fait et continue ses erreurs, ce serra évidement une raison
d'être + instant/long en blocage)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Message d'erreur d'iD concernant les "points"

2020-01-25 Par sujet marc marc
Le 25.01.20 à 21:34, Romain MEHUT a écrit :
> Le sam. 25 janv. 2020 à 21:24, marc marc a écrit :
> 
> 
> cela me semble une bonne idée, le commerce n'est pas une partie du
> contour mais qlq chose dans le batiment.
> 
> 
> C'est pourtant une pratique répandue de désigner un commerce à partir de
> là où on y accède. Marc j'imagine que tu vas répondre qu'il suffit de
> dissocier le point d'accès du commerce lui-même.

je répond qu'on confond la porte et le commerce.

conséquence pratique : dire la porte est accessible PMR sans savoir
ce qu'il en est du POI parce qu'il n'a pas été dedans POI.
ou le POI double porte (chose qu'on ne sait pas quand on est
devant la 1ere porte)
le poi au moins 1mm dans le bâtiment résout bien des problèmes.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Motorroad sur Trunk en France

2020-01-25 Par sujet marc marc
Le 25.01.20 à 21:12, Florimond Berthoux a écrit :
> un panneau "route pour automobile" après la premier sortie, 
> où le tag motorroad est fort utile.

pq cette partie n'est pas en highway=trunk ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Message d'erreur d'iD concernant les "points"

2020-01-25 Par sujet marc marc
Le 25.01.20 à 21:21, Romain MEHUT a écrit :
> iD râle si un nœud, décrit par exemple comme un commerce,
> est contigu du pourtour d'un bâtiment.

cela me semble une bonne idée, le commerce n'est pas une partie du
contour mais qlq chose dans le batiment.

 Je ne rencontre pas d'erreur avec JOSM

ce serrait une bonne idée à proposer
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Quel tag pour un magasin...

2020-01-25 Par sujet marc marc
Le 25.01.20 à 19:28, pepilepi...@ovh.fr a écrit :
> Je l'avais pas vu sur le wiki. Faut l'ajouter ?
> 

ce n'est jamais une mauvaise chose de documenter :)
au pire qlq rajoutera "p'tre pas une bonne idée d'un tag par produit" :p
mais il faudra avoir mieux à proposer, donc y gagnera aussi si cela
arrive :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Authentification fix-edit

2020-01-25 Par sujet marc marc
Le 25.01.20 à 13:40, Jacques Lavignotte a écrit :
> You must be logged in order to use the tag editor
> 
> Login :
> 
> La demande d’autorisation a échoué

sur la barre du menu, dernière élément "Connexion"
te renvoi vers https://osmose.openstreetmap.fr/fr/login
qui te renvois vers osm.org pour valider qu'osmose peux modifier les
données avec ton compte
c'est à quel moment que cela ne fonctionne pas ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Quel tag pour un magasin...

2020-01-25 Par sujet marc marc
Le 25.01.20 à 14:43, pepilepi...@ovh.fr a écrit :
> 
> ... dont la principale activité est la vente de cartouches d'encre pour
> imprimantes ?

je ne suis pas convaincu de la solution d'avoir un type de shoop=* pour
chaque magasin mono-produit mais il existe shop=printer_ink
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Bases ULM : sports_centre ?

2020-01-25 Par sujet marc marc
Le 25.01.20 à 13:07, deuzeffe a écrit :
> on fait comment pour renseigner qu'un tel terrain permet la
> pratique de l'ULM (à part sans le name=*) ?

séparer les 2 pour éviter la confusion du lieu global, de la piste et de
ce qui s'y passe

il y a la piste aeroway=airstrip éventuellement avec une référence (qui
me parait bien étrange pour être locale, locale serrait 1 2 3, ca m'a
plutôt d’être une ref qui est + étendue que locale)

s'il y a une base, alors c'est plus qu'une piste, c'est piste + route
d'accès + hangard + p'tre un local pour le public ou une buvette + p'tre
un parking. c'est le tout qui forme la base avec un polygone ou un noeud
si on connait mal l'étendue.

ou alors ce n'est pas une base dédié mais un club sportif qui utilise
une partie d'un aérodrome. alors plutôt un nœud, par exemple dans leur
hangar club=sport + sport=*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Afficher un flux WMS de l'ONF dans JOSM

2020-01-24 Par sujet marc marc
Le 24.01.20 à 15:35, Thomas Gratier a écrit :
> j'ai trouvé encore plus simple pour contourner proprement
> http://ws.carmencarto.fr/WMS/105/ONF_Forets?request=GetCapabilities=1.3.0

bravo pour ce travail de recherche complet \o/
une idée de la licence de cette couche ?
parce que si tout va bien, on ajoute dans josm/eli histoire que tout le
monde en profite sans devoir rajouter à la main une nouvelle couche
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] [AE] suppression ref:FR:SIREN de l'administration mis erronément mis sur place=*

2020-01-23 Par sujet marc marc
Bonjour,

Après la suppression des ref:INSEE  fin novembre,
il semle y avoir la même confusion avec ref:FR:SIREN
de nombreux place (par exemple un village) sont renseigné
avec le ref:FR:SIREN de la commune alors que c'est la ref
de l'administration de la commune.

voyez-vous un cas de figure la combinaison ref:FR:SIREN + place
est correcte ? sinon je propose une édition mécanique pour les supprimer

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


Re: [OSM-talk-fr] Repère géodésique hors des frontières communales

2020-01-23 Par sujet marc marc
Le 23.01.20 à 16:44, leni a écrit :
> Faudrait-il mieux déplacer la frontière dans osm ?

elle a été déplacée par import_fr en 2013 sans aucune source renseignée,
sans lien ou descriptif permettant de rafraichir la mémoire sur
l'opération. la version précédente était proche du cadastre

si tu la déplaces pour la mettre à l'endroit du cadastre,
le repère reste du mauvais côté... du coup pourquoi pas...
mais cela ne résoud pas le soucis.
si l'ign a elle aussi le soucis, alors faut leur écrire..
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


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

2020-01-23 Par sujet marc marc
Le 17.01.20 à 11:45, Vincent de Château-Thierry a écrit :
>>> Je suis partant pour faire partie de ce "pool".
>> je t'ajoute volontiers

j'ai donc ajouté Vincent en modérateur.

Philippe ayant résolu son soucis d'email wanadoo,
j'ai levé la modération de son compte
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Type de highway pour voie de bus

2020-01-23 Par sujet marc marc
Le 23.01.20 à 15:49, Philippe Verdy a écrit :
> C'est toujours la totalité du "way"

> L'attribut "foot=yes" est implicite pour quasiment tous les "highway=*"

Fait donc l'expérience de TA théorie :
prend donc n'importe quel highway=residential avec sidewalk=*,
vas-y sur place et met toi en plein milieu de la bande voiture,
restes-y une petite heure à faire des aller-retour sur cette bande
voiture pour que les forces de l'ordre ai le temps de réagir,
on verra si en France, un piéton circule sur "toujours la totalité
du way" comme tu dis ou si ta vision est décalage avec la réalité.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] intégration des voies sans addr : trouveur leur localisation

2020-01-23 Par sujet marc marc
Merci pour vos réponses.

Hélas le cadastre n'a aucune connaissance des 4 voies sans addr
que je cherchais.
j'ai utilisé l'analyse des pdf via http://cadastre.openstreetmap.fr
ce qui m'a permit de trouver un des lieux-dit nomé dans le nom de la
voie. j'ai trouvé/ajouté ce qui semble le seul chemin pour s'en
approcher mais le cadastre n'a pas de nom pour celui-ci.

pas grave, je passe à la commune suivante :)

Le 22.01.20 à 15:03, Jérôme Seigneuret a écrit :
> https://www.cadastre.gouv.fr/scpc/accueil.do  
> Et d'ailleurs on retrouve plein de choses bizarres avec des noms de
> voies qui n'ont pas été changé sur certaines parcelles... l'alias n'est
> pas utilisé dans le cadastre. En effet c'est très fastidieux.Si  pas de
> rattachement parcellaire et que la voie est quand même connu, ça ne va
> pas plus loin et ne te propose pas de planche.
> 
> 
> 
> Le mer. 22 janv. 2020 à 14:25, Vincent de Château-Thierry
> mailto:osm.v...@free.fr>> a écrit :
> 
> Bonjour,
> 
> > De: "marc marc"  <mailto:marc_marc_...@hotmail.com>>
> >
> > existe-t-il un moyen de chercher le cadastre pour trouver
> > la localisation d'une voie sans addr ?
> > http://dev.cadastre.openstreetmap.fr/fantoir/ ne donne pas de
> > coordonées
> > Sur la couche cadastre, elles apparaissent souvent mais visualiser
> > toute l'étendue d'une commune est fastidieux.
> >
> > ou autre outil ?
> 
> Si à la voie recherchée sont rattachées des parcelles, alors tu peux
> chercher le nom de voie ici :
> https://www.cadastre.gouv.fr/scpc/accueil.do
> Tu auras autant de réponses que de parcelles correspondantes (et de
> feuilles concernées) avec une visu carto.
> 
> vincent
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto: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


[OSM-talk-fr] passage en revue de l'utilisateur oc-OpenStreetMap

2020-01-23 Par sujet marc marc
Bonjour,

existe-t-il un outil pour lister les tags modifiés par un utilisateur ?
pas un changeset à la fois mais l'ensemble.
histoire de vérifier si ce sont des cas isolés à annuler à la main
https://www.openstreetmap.org/changeset/68406347
ou s'il faut faire appel au DWG pour un revert à grande échelle.

je ne suis demandeur d'un coup de main pour vérifier l'un ou l'autre
changeset au hasard car pour le moment je suis à 100% d'erreur.

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


Re: [OSM-talk-fr] Type de highway pour voie de bus

2020-01-23 Par sujet marc marc
je parle du cas simple, non tiré par les cheveux.
exemple https://www.openstreetmap.org/way/16405595
foot=yes ne veux donc pas dire "la rue entière est accessible
aux piétons" (sinon ce serrait un living_street ou qlq chose du genre).
foot=yes (explicite sur l'objet ou implicite en fct de la valeur du
highway=*) dit qu'un piéton a le droit de circuler sur au moins une
partie de la rue, les autres tags et la loi sont là pour dire si c'est
tout ou une partie.

Le 23.01.20 à 00:52, Philippe Verdy a écrit :
> Tu veux parler du cas particulier d'une rue barrée pour travaux avec une
> tranchée au milieu (interdite à tous avec des barrières autour, mais
> juste un passage de chaque côté par les trottoirs laissés libres pour
> les piétons (notamment les riverains qui doivent pouvoir encore entrer
> chez eux) ?
> Dans ce cas, oui les trottoirs sont obligatoires et on ne peut pas
> traverser la rue qui temporairement devient deux voies piétons séparées
> par des barrières et la tranchée, voire une seule voie d'un seul côté et
> sur une partie de la rue (juste ce qui est nécessaire pour laisser un
> accès aux riverains)
> Cependant ce n'est pas une situation durable, la tranchée dure quelques
> jours, et souvent elle se déplace. Cas qui existe pour une réfection des
> réseaux (égouts par exemple, mais il faut aussi rétablir ou maintenir
> les autres réseaux parallèles qui peuvent être temporairement dérivés:
> eau, gaz, électricité, téléphone/fibre).
> 
> Le mer. 22 janv. 2020 à 22:06, Stéphane Péneau
> mailto:stephane.pen...@wanadoo.fr>> a écrit :
> 
> Le 22/01/2020 à 20:41, marc marc a écrit :
> > Le 22.01.20 à 20:27, Stéphane Péneau a écrit :
> >> interdite à tout le monde, mais les trottoirs accessibles aux
> piétons.
> > access=no + foot=yes :)
> 
> Bah non, dans ce cas, la rue entière est accessible  aux piétons.
> Je parle de l'hypothétique cas où il n'y a que les trottoirs qui
> seraient accessibles à pied.
> 
> Stf
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org <mailto: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] Afficher un flux WMS de l'ONF dans JOSM

2020-01-23 Par sujet marc marc

> Philippe Verdy wrote
>> corriger la syntaxe XML, et utiliser ce fichier> pour accéder aux tuiles...

comment injecteras-tu ce xml modifié dans la réponse reçue par josm ?
cela sent le 100% vapoware !

Le 23.01.20 à 10:32, Romain MEHUT a écrit :
> Sauf que je n'ai pas les compétences pour faire ce que tu proposes en
> correctif :(

solution pragmatique : écrire à l'ONF pour signaler que tel url ne va
plus après avoir vérifié sur leur site si une nouvelle n'est pas dispo.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Type de highway pour voie de bus

2020-01-22 Par sujet marc marc
Le 22.01.20 à 22:06, Stéphane Péneau a écrit :
> Le 22/01/2020 à 20:41, marc marc a écrit :
>> Le 22.01.20 à 20:27, Stéphane Péneau a écrit :
>>> interdite à tout le monde, mais les trottoirs accessibles aux piétons.
>> access=no + foot=yes :)
> 
> Bah non, dans ce cas, la rue entière est accessible  aux piétons.
> Je parle de l'hypothétique cas où il n'y a que les trottoirs qui
> seraient accessibles à pied.

la loi ne dit-elle pas que le piéton doit marcher sur le trotoir quand
il y en a un ? et on ne tag pas la loi, juste les panneaux.
du coup je ne vois pas ce qui manque ou la différence avec n'importe
quel autre rue
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Type de highway pour voie de bus

2020-01-22 Par sujet marc marc
Le 22.01.20 à 20:27, Stéphane Péneau a écrit :
> interdite à tout le monde, mais les trottoirs accessibles aux piétons.

access=no + foot=yes :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] intégration des voies sans addr : trouveur leur localisation

2020-01-22 Par sujet marc marc
Bonjour,

existe-t-il un moyen de chercher le cadastre pour trouver
la localisation d'une voie sans addr ?
http://dev.cadastre.openstreetmap.fr/fantoir/ ne donne pas de coordonées
Sur la couche cadastre, elles apparaissent souvent mais visualiser
toute l'étendue d'une commune est fastidieux.

ou autre outil ?

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


Re: [OSM-talk-fr] Trottoir traversant

2020-01-21 Par sujet marc marc
cela aurait mérité d'être dans l'espace proposition
vu l'affinage en cours (ou pas apaprement)
cela me permet de simplifier ma réponse :)
je pense que tu oublies que les clefs osm n'ont pas nécessairement
le même sens dans osm qu'en anglais. plus précisement :

https://wiki.openstreetmap.org/wiki/FR%3AKey%3Ajunction
Décrit le type d'une jonction routière Edit or translate this description.
totalement axé "pour véhicule" et non intersection
cela ne me semble pas le bon choix de clef

kerb : axé obstacle piéton lorsqu'il croise une rue.
cela va compliquer l'utilisation des données si maintenant kerb=* décrit
aussi des traffic_claming=table sans que je percoive l'avantage

bref, dommage

Le 21.01.20 à 22:10, Florimond Berthoux a écrit :
> Bonsoir,
> 
> J'ai formalisé la réflexion sur cette nouvelle page
> https://wiki.openstreetmap.org/wiki/Continuous_Sidewalk
> 
> Réflexion faite, junction=continuous_sidewalk/continuous_cycleway sur le
> nœud d'intersection permet de préciser l'infra rapidement et de manière
> non ambigüe.
> Pour plus de précision on peut tagguer les ways avec
> junction=continuous_* et les kerbs.
> 
> Le ven. 17 janv. 2020 à 22:14, Florimond Berthoux
> mailto:florimond.berth...@gmail.com>> a
> écrit :
> 
> Le ven. 17 janv. 2020 à 10:37, marc marc  <mailto:marc_marc_...@hotmail.com>> a écrit :
> >
> > Je trouve que tu fais compliqué :)
> 
> En bon ingénieur j'énumère toutes les possibilités pour sélectionner
> la meilleure à la fin ;)
> 
> > une route et un trottoir se croise, donc un nœud d'intersection
> > "passage piéton" highway=crossing + crossing=uncontrolled probablement
> > pour le niveau de sécurité + crossing_ref=no probablement
> > pour le type (lié au marquage en fr be ch) + kerb=no
> 
> En fait il y a bien un kerb «A kerb (American English curb) is the
> edge where a road meets a sidewalk.»
> https://wiki.openstreetmap.org/wiki/Key:kerb
> Sauf que pour le trottoir traversant c'est la voiture qui se le
> prend cette fois, puisque le piéton lui reste sur le trottoir !
> Après, on pourrait interpréter le tag comme étant du point de vue du
> piéton, mais ce n'est pas définit comme cela.
> 
> > si tu veux maintenant ajouter du détail pour dire en linéaire
> > la longueur de ce croissement pour chaque usager :
> > - pour la voiture, c'est un plateau traffic_calming=table
> > sur le way voiture.
> > côté voiture, je vois pas de différence entre traverser
> > un plateau passage piéton avec marquage (les ""anciens"" trottoir
> > traversants qui existent depuis des années) et un plateau
> > passe piéton trottoir traversant).
> > tout autre tag me semble donc superflu ou erroné.
> > est-ce qu'il y a une différence dans la loi ?
> 
> Premier point, il y a différent type de trottoir traversant plus ou
> moins cassant pour une voiture, alors qu'un plateau traversant c'est
> bien réglementé (en France en tout cas).
> Second point, sur un plateau traversant il y a toujours une
> délimitation route/trottoir même s'ils sont censés être à niveau.
> Troisième point légal, en France, une voiture qui traverse un
> trottoir traversant traverse un trottoir (eh eh) et doit donc cédez
> le passage à tous à l'intersection (Article 415-9
> 
> https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=6ED1C96581529BBCE4CD62E5C0D68704.tplgfr41s_3?idArticle=LEGIARTI23095968=LEGITEXT06074228=20200117
> )
> 
> > - pour le piéton, il y a 2 incohérences dans ce que tu dis.
> > la clef crossing sert a décrire le passage piéton (le nœud même
> > si certain duplique l'info du passage 3 fois).
> > crossing=continuous n'est donc pas une bonne idée pour décrire
> > l'étendue du cheminement de voie le composant.
> > par ailleurs si tu considères qu'un trottoir traversant est un
> trottoir,
> > alors ce n'est pas un passage piéton, c'est highway=path path=sidewalk
> > si c'est pas tout a fait un trottoir (peut-on s'y arrêter pour faire
> > ses lacets ou discuter avec un autre pendant 5 min ? j'en doute),
> > alors highway=path path=continuous_sidewalk ou qlq chose du genre.
> 
> C'est un vrai trottoir et tu peux jouer à la marelle dessus, c'est
> comme une entrée charretière, après personne n'a le droit d’empêcher
> l'autre de passer ;)
> Oui crossing ça veut vraiment dire passage pour traverser la grosse
> voie (route, chemin de fer, rivière...).
> 
> Et le mot anglais pour intersection c'est ... junction
> https://wik

Re: [OSM-talk-fr] Repère géodésique hors des frontières communales,relation 526301

2020-01-21 Par sujet marc marc
si tu passes par là : vérifier que le clocher est tjs là, si oui
- mettre un survey:date=2020-01 sur les repères
- flager l'anomalie en faux positif sur osmose

Le 21.01.20 à 16:03, Jacques Lavignotte a écrit :
> Je conclue qu'on laisse tel-quel.
> 
> J'aime bien quand il n'y a rien à faire :)
> 
> Merci, J.
> 
> 
> Le 21/01/2020 à 15:47, GarenKreiz a écrit :
>> En cherchant dans les fichiers de données qui avaient servi à injecter
>> les points géodésiques dans OSM, j'ai retrouvé les deux repères : la
>> base de la croix du clocher et le centre de la croix. Si le clocher
>> est toujours là, ces points sont de fait toujours présents mais sans
>> repère matériel spécifique. C'est donc l'IGN qui semble avoir décidé
>> de les rendre obsolètes.
>>
>> Comme cela peut servir à caler du bâti ou des photos aériennes, il
>> serait peut-être utile de les garder dans la base.
>>
>> Cordialement
>>
>>     Garenkreiz
>>
>> On Tue, 21 Jan 2020 at 12:56, marc marc > <mailto:marc_marc_...@hotmail.com>> wrote:
>>
>>     Le 21.01.20 à 10:00, Jacques Lavignotte a écrit :
>>  > je ne sais qu'en faire...
>>
>>     https://www.openstreetmap.org/relation/526301
>>     ref 86194A introuvable sur le site de l'ign
>>     recherche sur Poitiers puis zoom sur le lieu
>>     montre bien l'église mais point géodésique.
>>
>>     j'ignore si on peux chercher les points détruit.
>>     ___
>>     Talk-fr mailing list
>>     Talk-fr@openstreetmap.org <mailto: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] Talk sur lecteur de news: news.gmane.org devient news.gmane.io

2020-01-21 Par sujet marc marc
Le 21.01.20 à 15:37, FR via Talk-fr a écrit :
> Bonsoir

ou bonjour :)

> https://lars.ingebrigtsen.no/2020/01/06/whatever-happened-to-news-gmane-org/
> https://lars.ingebrigtsen.no/2020/01/15/news-gmane-org-is-now-news-gmane-io/

pour ceux qui veulent un résumé : il a voulu vendre, l'autre gars a pris
le domaine mais ne répond plus depuis qu'il faut migrer l'ip de
l'hébergement. donc il reprend la main en changeant de domaine

> Question aux admin des listes hébergées par "listes.openstreetmap.fr/" :
> apparemment elle ne sont pas disponibles sur gmane. Serait possible d'y
> remédier?

je suis une chaud partisan de la messagerie unifiée (avoir les mêmes
messages sous différents formats/protocoles : mail, news, forum, ...)
afin que chacun puisse choisir le sien sans fragmenter la communauté.

Mais avec ma casquette ad-hoc, je pense que côté osm-fr, il nous reste
d'abord à mettre en place l'anti-spam en entrée (et p'tre même sortie)
avant de s'interconnecter +.

Se pose aussi la question (sans avoir analysé la chose) de la modération
(qui est courante, principalement justement pour virer les spams) qu'il
faudrait éviter à devoir faire plusieurs fois.

> ça évite de télécharger les mails sur le disque dur.

cela a beaucoup d'avantage mais pas celui là :
ton client "news" télécharge de toute façon ton message et en garde
généralement une copie sur ton disque dur pour éviter de le télécharger
à chaque fois que tu le sélectionnes.

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


Re: [OSM-talk-fr] Repère géodésique hors des frontières communales,relation 526301

2020-01-21 Par sujet marc marc
Le 21.01.20 à 10:00, Jacques Lavignotte a écrit :
> je ne sais qu'en faire...

https://www.openstreetmap.org/relation/526301
ref 86194A introuvable sur le site de l'ign
recherche sur Poitiers puis zoom sur le lieu
montre bien l'église mais point géodésique.

j'ignore si on peux chercher les points détruit.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Pépinière d'arbres fruitiers en venet directe

2020-01-21 Par sujet marc marc
ma proposition shop=garden_centre est loind d'être parfaite
mais un magasin à la ferme vend quand même rarement des arbres.

origin=producer me semble une tautologie (tous les produits viennent
de leur producteur) mais me fait penser à origin=own pour décrire
les producteurs/vendeurs

Le 21.01.20 à 10:57, Florimond Berthoux a écrit :
> Oups, j’ai lu trop vite, désolé.
> 
> Le shop=farm pourrait tout de même peut-être être utilisé ici ?
> Ou origin=producer me semble bien aussi.
> 
> Le mar. 21 janv. 2020 à 10:53, marc marc  a écrit :
>>
>> une pépinière qui vend des arbres fruitiers n'est pas un vVerger qui
>> produit des fruits :) les arbres y sont souvent trop jeunes et/ou y
>> restent trop peu de temps pour produire.
>>
>> Le 21.01.20 à 10:28, Florimond Berthoux a écrit :
>>> Bonjour,
>>>
>>> De ce que j’en comprend:
>>> landuse=orchad pour un verger (plant_nursery c’est pour les bébés
>>> plantes, qui ne produisent donc pas encore de fruit)
>>> tu peux ajouter trees=* et produce=* pour préciser le type de verger.
>>>
>>> Ensuite ce qui n’est pas clair : est-ce de la vente directe
>>> producteur->consommateur, ou les consommateurs vont cueillir lui même
>>> sur l’arbre ?
>>>
>>> Pour le premier cas c’est simplement un magasin de fruit à mettre sur
>>> le bâtiment du magasin :
>>> shop=greengrocer
>>>
>>> puis pour préciser que c’est de la vente directe:
>>> origin=producer ?
>>>
>>> mais je lis dans la page shop:
>>> «shop=farm - A seasonal outlet for goods produced on a given farm.»
>>>
>>> Pour la cueillette, je ne sais.
>>>
>>>
>>> Manger des pommes, cordialement.
>>>
>>> Le lun. 20 janv. 2020 à 21:16, marc marc  a 
>>> écrit :
>>>>
>>>> Bonjour,
>>>>
>>>> Le 20.01.20 à 18:17, Alain Rpnpif a écrit :
>>>>> Je cherche une balise pour les pépinières d'arbres fruitiers en vente
>>>>> directe (c'est la saison !).
>>>>
>>>> shop=garden_centre
>>>> vending=fruit_tree ou vending=tree
>>>>
>>>> pour la vente directe, je ne me souviens pas d'un tag.
>>>>
>>>> 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
> 
> 
> 

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


Re: [OSM-talk-fr] Pépinière d'arbres fruitiers en venet directe

2020-01-21 Par sujet marc marc
une pépinière qui vend des arbres fruitiers n'est pas un vVerger qui
produit des fruits :) les arbres y sont souvent trop jeunes et/ou y
restent trop peu de temps pour produire.

Le 21.01.20 à 10:28, Florimond Berthoux a écrit :
> Bonjour,
> 
> De ce que j’en comprend:
> landuse=orchad pour un verger (plant_nursery c’est pour les bébés
> plantes, qui ne produisent donc pas encore de fruit)
> tu peux ajouter trees=* et produce=* pour préciser le type de verger.
> 
> Ensuite ce qui n’est pas clair : est-ce de la vente directe
> producteur->consommateur, ou les consommateurs vont cueillir lui même
> sur l’arbre ?
> 
> Pour le premier cas c’est simplement un magasin de fruit à mettre sur
> le bâtiment du magasin :
> shop=greengrocer
> 
> puis pour préciser que c’est de la vente directe:
> origin=producer ?
> 
> mais je lis dans la page shop:
> «shop=farm - A seasonal outlet for goods produced on a given farm.»
> 
> Pour la cueillette, je ne sais.
> 
> 
> Manger des pommes, cordialement.
> 
> Le lun. 20 janv. 2020 à 21:16, marc marc  a écrit :
>>
>> Bonjour,
>>
>> Le 20.01.20 à 18:17, Alain Rpnpif a écrit :
>>> Je cherche une balise pour les pépinières d'arbres fruitiers en vente
>>> directe (c'est la saison !).
>>
>> shop=garden_centre
>> vending=fruit_tree ou vending=tree
>>
>> pour la vente directe, je ne me souviens pas d'un tag.
>>
>> 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] Pépinière d'arbres fruitiers en venet directe

2020-01-20 Par sujet marc marc
Bonjour,

Le 20.01.20 à 18:17, Alain Rpnpif a écrit :
> Je cherche une balise pour les pépinières d'arbres fruitiers en vente
> directe (c'est la saison !).

shop=garden_centre
vending=fruit_tree ou vending=tree

pour la vente directe, je ne me souviens pas d'un tag.

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


Re: [OSM-talk-fr] Récupération des points d'apport volontaire (déchets)

2020-01-20 Par sujet marc marc
Le 20.01.20 à 20:54, emeric Prouteau a écrit :
> quels ont été les arguments ? 

te placer à leur place : pourquoi cela leur est utile de passer
du temps à les produire s'ils n'ont pas l'info toute prête ?
si tu as le site de la commune utilisant osm, c'est évidement un grand plus.
si tu as des assos locales, un comité de quartier, ... idem.
sinon, une couche sur "moyen facile et à jour (mais ils vont facilement
pouvoir te dire que eux sont la source la plus à jour).
et puis le collaboratif... mais là c'est beaucoup plus lent à faire
comprendre
une dernière piste : ne pas parler spécialement d'osm mais dire que
"c'est pas à jour partout, puis-je avoir la liste officielle" ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Conflit entre attributs : amenity, place item=4030, class=900, level=1

2020-01-20 Par sujet marc marc
Le 20.01.20 à 11:29, Jacques Lavignotte a écrit :
> http://osmose.openstreetmap.fr/map/#zoom=16=46.7721117=0.4255099=4030=1

j'ai pris le premier :
https://www.openstreetmap.org/node/676827734
soit cela représente la marie, soit le village, mais pas les 2 à la fois.
le mieux me semble être de supprimer l'attribut mairie+ (parce que c'est
ce noeud qui est aussi admin_center de la commune, donc il représente le
village) et supprimer aussi siren pour ne garder que village et de
déplacer le noeud du village un rien + loin.
ensuite créer un 2ieme noeud mairie

> Le Wiki dit que c'est parfois légitime.

sans doute, mais j'ai encore jamais vu le cas :)

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


Re: [OSM-talk-fr] OpenStreetMap un bloatware ?

2020-01-18 Par sujet marc marc
Le 18.01.20 à 18:10, Stéphane Péneau a écrit :
> J'ai été assez surpris d'un commentaire sur linuxfr, qui citait
> OpenStreetMap dans sa liste des "bloatwares" [1]. Après lui avoir
> demandé comment il en était arrivé à cette conclusion, sa réponse [2] me
> donne l'impression qu'il mélange la BDD, et le rendu. Je me trompe ?
> 
> [1] https://linuxfr.org/nodes/119088/comments/1796042
> 
> [2] https://linuxfr.org/nodes/119088/comments/1796846

il y a beaucoup de "caricature simpliste d'un monde complexe"
mais je trouve qu'il y a quand même un part de vrai :
les serveurs osm.org de rendu par exemple, c'est un exemple de pelote,
tellement emmelé que leur évolution a du mal.

ceci dit, là où il se trompe à mes yeux, c'est que l'empilement permet
de réutiliser des briques simples au lieu d'inventer un nouveau Xieme
protocole ou Xieme brique qui fait quasi pareil que l'existant mais qui
a 1% de différence "d'optimisation" et qui au final rendra le moins
performant ou moins facile à maintenir (parce qu'à chaque amélioration
de la brique standard, il faudra du temps pour maintenir
le fork optimisé). On a cela pas loin...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Supermarché drive only

2020-01-18 Par sujet marc marc
Le 18.01.20 à 20:25, Cédric Frayssinet a écrit :
> Le 12/01/2020 à 19:33, marc marc a écrit :
>> Le 06/01/2020 à 22:23, Cédric Frayssinet a écrit :
>>> Avez-vous déjà tagué ce genre de magasin :
>>> https://westnordost.de/p/7258.jpg
>> si c'était un drive only
>> shop=supermarket
>> drive_through=only
>>
>> mais à voir la photo, ce n'est pas le cas,
>> tu sorts de ton véhicule et tu vas dans le magasin,
>> comme n'importe quel autre magasin sauf que t'as passé
>> ta commande avant au lieu de sur place.
>> je n'ai pas connaissance de tag disant que le magasin
>> a la possibilité de commander en ligne.
>> si tu le trouve, suffit de mettre =only
> 
> 
> Du coup, j'ai pris exemple sur les lockers Amazon et j'ai mis ces tags :

c'est une bonne idée. mais je ne suis pas d'accord avec qlq détails :

> vending=parcel_pickup

vending c'est le produit vendu (le truc avec lequel tu repart)
On n'y vend pas des "parcel_pickup",
On y vend de la nourriture, boisson et autre.

> covered=yes

cela n'avait pas l'air d'être couvert mais dans un bâtiment.

> description=Consignes permettant de retirer ses courses 24h/24h

virer le 24h/24 puisqu'il se trouve dans un tag (sinon on finit
inutilement par copier tous les tags dans description)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Conciergerie ?

2020-01-18 Par sujet marc marc
Le 18.01.20 à 19:30, Cédric Frayssinet via Talk-fr a écrit :
> chaîne de conciergerie technique : http://lesjules.com/

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


Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

2020-01-18 Par sujet marc marc
Le 18.01.20 à 19:03, Philippe Verdy a écrit :
> Le cas "private" ne devrait pas exister pour les stations de recharge

réponse d'un gars qui en ajoute :
un jour je passes devant un immeuble, il y une borne, je l'ajoutes dans osm.
la fois d'après que t'y vas, tu vas en avance pour noter les détails
(opérateur, prise, ...) et là t'apprends que c'est d'accès privé.
supprimer la borne d'osm serait une erreur parce que le prochain va
refaire la même recherche une 2ieme fois.
alors access=private a tous son sens... surtout que la prochaine fois
j'irai discuter avec le gars voir s'il n'a pas envie de la rendre dispo
à la demande comme un autre l'a fait avant lui.
ouais le collaboratif, c'est pas que osm.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

2020-01-18 Par sujet marc marc
a noter qu'il y a aussi la clef charging_station=*
https://taginfo.openstreetmap.fr/keys/charging_station
permettant de renseigner qu'un poi a une station de recharge
lorsqu'on ignore exactement où il se trouve

au final cela fait quelques choses du genre :

area[name="Cabourg"];
nwr[amenity=charging_station]->.borne;
(
nwr(around.borne:100)[tourism=hotel];
nwr[tourism=hotel][charging_station][charging_station!=no];
);
(._;>;);
out meta;


Le 18.01.20 à 10:40, Vincent Bergeot a écrit :
> Le 18/01/2020 à 02:09, Shohreh a écrit :
>> trouver tous les hôtels en France qui proposent une
>> prise pour recharger une voiture électrique
> 
> area[name="Cabourg"];
>   node(area)[tourism=hotel]->.hotels;
>   (
>     way(around.hotels:100)[amenity=charging_station];
>     node(around.hotels:100)[amenity=charging_station];
>   );
>   (._;>;);
>   out meta;
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Hôtels équipés de prises pour voitures électriques ?

2020-01-18 Par sujet marc marc
Le 18.01.20 à 12:25, Shohreh a écrit :
> distinguant les prises en accès privé/public ?

access=private/customers/yes (l'absence de la clef signifiant yes)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Types de prises IRVE

2020-01-17 Par sujet marc marc
Bonjour,

Le 17.01.20 à 12:29, emeric Prouteau a écrit :
> Je souhaite intégrer les IRVE

VE ok mais IRVE c'est quoi ?
wikipedia ne connait que https://en.wikipedia.org/wiki/IRVE

> manquantes de Dordogne basé sur la donnée mobive disponible sur data.gouv.

de combien d'objet parle-t-on ?
ayant corrigé des horreurs de précédent import un peu partout
cela serrait sûrement profitable de faire une conversion propre via
osmose une fois pour toute.

> Le wiki : https://wiki.openstreetmap.org/wiki/Key:socket
>   * CHADEMO (Ca c'est Ok)

socket:chademo :)

>   * COMBO

socket:type2_combo

>   * EF
>   * T2 - EF

je ne connait pas, une photo ?
dans la base osm, il y a UN socket=EF-T3 (justement
un import qui ne respecte pas la syntaxe courante)

>   * T2

socket:type2

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


  1   2   3   4   5   6   7   8   9   10   >