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

[Arnaud Champollion]

Le 17/02/2020 à 19:19, osm.sanspourr...@spamgourmet.com a écrit :


shelter_type=borie (voir la valeur plus standard un point-virgule et 
le nom). Pas fana non plus borie c'est du français, pas de l'anglais.




On a bien amenity=lavoir

Sinon je serais tenté quand même de mettre description=borie.


shelter_type=basic_hut
material=dry_stone

suffit pour décrire une cabane en pierre sèche.



Je résume donc où j'en suis :

amenity=shelter
material=dry_stone
shelter_type=basic_hut
description=borie

Ce fut un abri et c'en est toujours un, même si l'usage a changé (de 
cabane de berger, il reste plutôt la possibilité de s'y abriter en rando 
quand la voûte est intacte).
Je laisse tomber historic=shelter puisque c'est toujours un abri, même 
si sa fonction actuelle est aussi patrimoniale (sans être archéologique).



___
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 ?

[osm . sanspourriel]

Le 17/02/2020 à 17:32, Christian Quest - cqu...@openstreetmap.fr a écrit :



Le 17/02/2020 à 11:55, osm.sanspourr...@spamgourmet.com a écrit :

Le 17/02/2020 à 09:37, Christian Quest - cqu...@openstreetmap.fr a
écrit :

Dans l'exemple donné, on a un lotissement qui pourrait très bien se
satisfaire d'un landuse=residential nommé.


Le problème c'est la juxtaposition et/ou l'empilement de landuse de même
type.

De plus tu vas avoir inévitablement des duplications de noms
landuse/place.

Non seulement on n'a pas d'information relative à l'importance (sauf la
surface), mais en plus il y a des scories d'affichage.



La surface est justement utilisée pour l'ordre de rendu.

On peut aussi mettre le lotissement en inner du residential plus
général qui est autour.


Dans les deux cas tu as des scories d'affichage : les landuse ont, outre
une couleur de fond, un bord.

Du coup ton landuse est coupé visuellement comme s'il y avait des
clôtures entre.


Le 17/02/2020 à 09:37, Christian Quest - cqu...@openstreetmap.fr a
écrit :

Dans le cas présent d'un quartier/lotissement définit en surfacique,
je ne vois pas ce qu'apporte le ponctuel arbitraire.


L'affichage puisque le place= n'est rendu que sur le ponctuel. Sauf à le
modéliser en landuse qui ne me semble pas correct.

Un quartier n'est par exemple pas nécessairement constitué que d'une
zone résidentielle, il peut y avoir de la zone commerciale, de
l'industrie...


N. B. : le rôle label n'est pas indispensable il permet de faire le lien
entre les deux.

Si les rendus utilisaient les place= surfaciques, on pourrait supprimer
les place= ponctuels redondants.


Sur le polygone je mettrais:
landuse=residential
place=neighborhood
name=Lotissement Machinchose


C'est bien ça que j'ai supprimé car ni le rendu ni la modélisation ne me
semblaient bonnes.

Exemple : il y a avait un landuse  (déjà le nom pose problème,
ça duplique le nom et la commune n'est pas la zone agglomérée centrale)
et des landuse Lotissement Machinchose.

Ça découpait visuellement le bourg alors que les lotissements/résidences
sont intégrés au bourg.

Jean-Yvon



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

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

[Marc Mongenet]

Bonsoir,

Je cartographie depuis une bonne dizaine d'années le Grand Genève, et pour
les chemins agricoles et forestiers j'utilise toujours:
* track grade1 lorsque la chaussée est revêtue, ce qui donne généralement
des bords de chaussée distincts en photo aérienne;
* track grade2 lorsque toute la chaussée est en terre ou gravier, mais sans
herbe;
* track grade3 lorsque le centre de la chaussée est en herbe mais pas les
traces de pneus;
* track grade4 lorsque les traces de passage sont discernables mais
discontinues
* track grade5 lorsque la piste est indiscernable ou à peine (de l'herbe
partout)
En bref, je me fonde sur les photos du wiki, qui n'ont pas varié depuis
bien longtemps (toujours?)
Je passe parfois des chaussées au revêtement particulièrement dégradé, ou
recouvert de terre, en grade2.
Bien sûr ces critères dépendent du climat local.

Pour moi,
https://www.mapillary.com/app/?focus=photo=IKTSczR_C0BrDrSTYcyDPg=42.72720613999894=2.712138949997893=17
est
sans hésitation du track grade2.

Parmi les erreurs que je rencontre souvent, il y a:
highway=service au lieu de track grade1, probablement pour mapper en
fonction du joli rendu de highway=service.
highway=path au lieu de track grade3 à grade5, probablement par erreur ou
manque d'information (mapping de traces GPS prises à pied/vélo).

Marc Mongenet


Le lun. 17 févr. 2020 à 07:34, rainerU  a écrit :

> Bonjour,
>
> Dans les départements 11 et 66, un utilisateur a récemment ajouté ou
> modifié un
> grand nombre de pistes de montagne. Les valeurs qu'il utilise pour
> tracktype
> sont généralement un ou deux niveaux supérieurs à celles que
> j'utiliserais,
> c'est à dire, là ou je mets grade3 ou grade2 il met grade1. J'ai laissé un
> commentaire sur un de ses changeset avec des liens vers des images
> Mapillary :
>
> https://www.openstreetmap.org/changeset/79978741
>
> J'ai déjà eu le même genre de discussion avec lui en 2013. En gros, sa
> règle est
> : ce qui est goudronné est unclassifed, lest track c'est tout ce qui n'est
> pas
> goudronné, donc le grade1 est pour les "chemins empierrées larges,
> roulables en
> voiture standard". Moi, je me tiens à la définition du wiki de grade1 :
> "revêtement dur de type asphalte ou composée de matériaux très compactés".
>
> Comme je ne suis pas entièrement sur d'avoir la bonne vision des règles
> d'utilisation de tracktype et avant d'entamer une guèrre d'édition, je
> vous
> demande votre avis sur ces modifications.
>
> Rainer
>
>
> ___
> 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] Vandalisme utilisateur "PARIS SUD", le retour

[osm . sanspourriel]

En MP, Noémie et moi parlions de revitaliser le MapRoulette consacré à
RB94 :

https://maproulette.org/challenge/3443/task/7996740

Comme ça on se partage le boulot sans devoir se coordonner expressément.

Effectivement si quelqu'un est déjà intervenu entre temps, je ne sais si
la requête de Noémie le verra ou passera à travers.

Marc : tiens j'en ai pris un au hasard :

https://www.openstreetmap.org/node/5894483018/history

Et hop un que j'avais corrigé avec un commentaire qui était assez
clair... Ça donne plus envie de faire un revert sur les changesets en
question !

Jean-Yvon

Le 17/02/2020 à 21:26, marc marc - marc_marc_...@hotmail.com a écrit :

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



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

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

[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] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Stéphane Péneau]

Le 17/02/2020 à 20:02, severin.menard via Talk-fr a écrit :


Pour la solution basée sur le boîtier Drotek Sirius utilisant la carte 
ublock F9, que faut-il prévoir en plus côté accessoires ?





Un gros trépied ?


Oui


De quoi l'alimenter ?


Batterie fournie


Un boîtier étanche pour les intempéries ?


Le mieux est peut-être de leur demander



Et côté softs ?

Tu peux presque tout faire avec RTKLib qui est FOSS. Ce fork est 
recommandé : https://github.com/rtklibexplorer/RTKLIB



Si j’ai bien compris, l’idée n’est pas de créer une base GNSS comme le 
montrait Stéphane dans sa présentation, mais d’avoir deux récepteurs 
qui enregistrent leur position de manière Indépendante et du 
post-traitements une fois le terrain fini ?


L'idée c'est d'utiliser un récepteur en tant que base qui pourra être 
déplacée de temps en temps. Mais pour que les coordonnées de cette base 
soit correctes, il faudra tout de même la laisser assez longtemps 
(plusieurs heures) sur un endroit fixe.


Quelle surface tu souhaites couvrir ?

Y a-t-il d’autres personnes que moi qui seraient intéressées par un 
atelier pratique lors du SotM de Nantes sur toute la chaîne des deux 
approches Ublock en PPP et deux ublocs + ? Je pourrais amener un ou 
deux Drotek.



Pourquoi pas.

Stf


___
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 ?

[osm . sanspourriel]

Dans tes choix, vérifie que le signal Galileo est capté car là tu as "en
brut" de la précision métrique.

Ce n'est pas ce que tu cherches, mais c'est déjà sans doute suffisant :

En général en France on utilise le cadastre et BDOrtho qui utilisent un
repère propre, tectoniquement stable et non le WGS84. Il y a
actuellement 80 cm de différence (de mémoire).

Jean-Yvon

Le 17/02/2020 à 20:02, severin.menard via Talk-fr -
talk-fr@openstreetmap.org a écrit :


Bonjour à tou-te-s,

Merci pour les nombreuses réponses et conseils sur ce fil !

Pour la solution basée sur le boîtier Drotek Sirius utilisant la carte
ublock F9, que faut-il prévoir en plus côté accessoires ? Un gros
trépied ? De quoi l'alimenter ? Un boîtier étanche pour les
intempéries ? Et côté softs ? Je vais devoir faire établir un devis et
ne voudrais rien oublier.

Le seul intérêt du matériel que j’avais trouvé sur le net est qu’il
soit apparemment capable de recevoir les infos différentielles
Omnistar, le seul service (payant sous abonnement) qui semble couvrir
l’Afrique subsaharienne. Comme c’est malheureusement un machin
propriétaire qui exige que le récepteur soit compatible
(https://en.wikipedia.org/wiki/OmniSTAR), je pense que le Drotek ne
doit pas pouvoir l’utiliser. Mais pour éviter de rester des jours sur
un même point en mode PPP, il y a donc la méthode intéressante
proposée par Éric d’avoir un récepteur fixe et un autre mobile, ce qui
rend l’organisation du terrain plus facile. Si j’ai bien compris,
l’idée n’est pas de créer une base GNSS comme le montrait Stéphane
dans sa présentation, mais d’avoir deux récepteurs qui enregistrent
leur position de manière Indépendante et du post-traitements une fois
le terrain fini ?

Y a-t-il d’autres personnes que moi qui seraient intéressées par un
atelier pratique lors du SotM de Nantes sur toute la chaîne des deux
approches Ublock en PPP et deux ublocs + ? Je pourrais amener un ou
deux Drotek.


Séverin






___
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] Bon usage de tracktype

[Sébastien Dinot]

Bonjour,

rainerU a écrit :
> J'ai déjà eu le même genre de discussion avec lui en 2013. En gros, sa
> règle est : ce qui est goudronné est unclassifed, lest track c'est
> tout ce qui n'est pas goudronné, donc le grade1 est pour les "chemins
> empierrées larges, roulables en voiture standard".

Je fais de même. J'ai pris cette habitude en cartographiant une région
d'Italie (les Marches) dans laquelle je me rends souvent et qui compte
de nombreuses pistes non goudronnées, mais recouvertes d'un gravier
compact blanc (enfin, plutôt beige écru). Pour moi, sur une route
goudronnée, que je déclare « unclassified », il est possible de rouler
à bonne allure car le revêtement procure une bonne adhérence et on peut
avoir une relative confiance sur la continuité du revêtement. Pas de
doute, c'est une « route ». Sur une voie en gravier, non seulement
l'adhérence est faible, mais il arrive que le ravinement fasse de gros
dégâts. Il est hors de question de rouler à 50 km/h sur une telle voie
ou même de la privilégier à une route goudronnée à peine plus longue.
J'indique donc que cette voie non goudronnée est une « piste » et si sa
surface est plane et homogène, j'indique que son « tracktype » est
« grade1 ».

Il me semble notamment important de distinguer les deux pour le
routage : il faut privilégier les axes goudronnés. Je me souviens d'une
fois où mon GPS m'a fait prendre une route de 8 km pour accéder à un
plateau en montagne. La « route » s'est révélée être une piste couverte
de ce gravier écru et était très défoncée. J'ai du faire une bonne
partie du trajet au pas. Arrivé au sommet de la montagne, j'ai eu la
surprise de me retrouver face à une belle route, large, goudronnée et
lisse. Je me suis demandé pourquoi mon GPS m'avait fait prendre la piste
déglinguée. J'ai constaté que les deux voies étaient considérées comme
équivalentes dans la base de mon GPS, mais que la route goudronnée
faisait 9 km (soit 1 km de plus que la piste). Mon GPS m'a donc fait
prendre le chemin le plus court. De retour à la maison, j'ai constaté le
même problème dans OSM et je me suis empressé de rectifier le tir.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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

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

[severin.menard via Talk-fr]

Bonjour à tou-te-s,

Merci pour les nombreuses réponses et conseils sur ce fil !

Pour la solution basée sur le boîtier Drotek Sirius utilisant la carte ublock 
F9, que faut-il prévoir en plus côté accessoires ? Un gros trépied ? De quoi 
l'alimenter ? Un boîtier étanche pour les intempéries ? Et côté softs ? Je vais 
devoir faire établir un devis et ne voudrais rien oublier.

Le seul intérêt du matériel que j’avais trouvé sur le net est qu’il soit 
apparemment capable de recevoir les infos différentielles Omnistar, le seul 
service (payant sous abonnement) qui semble couvrir l’Afrique subsaharienne. 
Comme c’est malheureusement un machin propriétaire qui exige que le récepteur 
soit compatible (https://en.wikipedia.org/wiki/OmniSTAR), je pense que le 
Drotek ne doit pas pouvoir l’utiliser. Mais pour éviter de rester des jours sur 
un même point en mode PPP, il y a donc la méthode intéressante proposée par 
Éric d’avoir un récepteur fixe et un autre mobile, ce qui rend l’organisation 
du terrain plus facile. Si j’ai bien compris, l’idée n’est pas de créer une 
base GNSS comme le montrait Stéphane dans sa présentation, mais d’avoir deux 
récepteurs qui enregistrent leur position de manière Indépendante et du 
post-traitements une fois le terrain fini ?

Y a-t-il d’autres personnes que moi qui seraient intéressées par un atelier 
pratique lors du SotM de Nantes sur toute la chaîne des deux approches Ublock 
en PPP et deux ublocs + ? Je pourrais amener un ou deux Drotek.

Séverin___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[osm . sanspourriel]

Le 17/02/2020 à 18:26, Arnaud Champollion -
arnaud.champoll...@linux-alpes.org a écrit :


Du coup est-ce que ça veut dire qu'on peut cumuler :

building=shelter pour dire que *c'est* un abri
historic=shelter pour dire que *ce fut* un abri
amenity=shelter pour dire que ça peut être *utilisé* comme abri


Non, dans OSM on met essentiellement ce qui est.
Tu ne peux avoir historic=shelter et amenity=shelter.
Soit ce fut un abri et ça ne l'est plus historic=shelter
Soit ce fut un abri et ça l'est toujours amenity=shelter

Tu peux ajouter start_date=1848 si tu veux dire que c'est un abri depuis
1848.

Ou end_date=1970 pour dire que ce n'est plus un abri depuis 1970.

Si c'est juste du petit patrimoine ordinaire, à la place de historic,
peut-être was:amenity=shelter.

> building:loc=borie (si building=shelter, mais du coup où mettre borie
dans le cas où on n'utilise pas building ?)

Non, building:loc c'est la création ex abrupto d'un contributeur isolé.

Éventuellement building=borie ou shelter_type=borie (voir la valeur plus
standard un point-virgule et le nom). Pas fana non plus borie c'est du
français, pas de l'anglais.

shelter_type:FR=borie pour faire réagir Marc^^.

Quand je vois https://fr.wikipedia.org/wiki/Cabane_en_pierre_s%C3%A8che

Je me dis que :

shelter_type=basic_hut

material=dry_stone

suffit pour décrire une cabane en pierre sèche. KISS, que les gens en
Provence ou ailleurs aient un terme spécifique, ça ne me dérange pas
mais la base est mondiale.

description et wikipedia : non, ça doit être spécifique à l'objet, là
c'est de la tautologie autour des tags.

Je réponds ainsi à tes questions :

> building=shelter (si le bâtiment est toujours debout, sinon ruins ?)
OK, mais il faut quand même qu'il reste plus qu'un tas de cailloux !

> building:loc=borie (si building=shelter, mais du coup où mettre borie
dans le cas où on n'utilise pas building ?)
Dans tous les cas tu oublies borie, ce n'est pas de l'anglais britannique.

> building:material=dry_stone (même question, où mettre dry_stone si on
n'utilise pas building ?)
material est plus général.

Jean-Yvon
___
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 ?

[Stéphane Péneau]

Le 17/02/2020 à 17:28, osm.sanspourr...@spamgourmet.com a écrit :

Le 17/02/2020 à 17:20, Eric SIBERT via Talk-fr -
talk-fr@openstreetmap.org a écrit :


alors que pour ceux qui ont déjà un smartphone...


RTKGPS ?



RTKGPS n'est que RTKLIB pour Android. Il faut tout de même un récepteur 
qui propose les données "RAW", ce qui est plutôt rare sur les 
smartphones, et les résultats sont ... moyens ... pour cause d'antenne 
pas terrible.



Stf


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

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

[Arnaud Champollion]

J'ai bien lu ton message, essayé de bien comprendre et synthétiser une 
méthode (ci-dessous, avec mes questionnements encore)

Merci,



Le 17/02/2020 à 12:03, marc marc a écrit :

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 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).



Du coup est-ce que ça veut dire qu'on peut cumuler :

building=shelter pour dire que *c'est* un abri
historic=shelter pour dire que *ce fut* un abri
amenity=shelter pour dire que ça peut être *utilisé* comme abri


Au final j'imagine :

historic=shelter   (dans tous les cas car ce sont bien tous d'anciens abris de 
bergers)

building=shelter   (si le bâtiment est toujours debout, sinon ruins ?)

amenity=shelter(si on peut toujours l'utiliser)

shelter_type=basic_hut   (possible car il y a au moins un shelter)

building:loc=borie   (si building=shelter, mais du coup où mettre borie dans le 
cas où on n'utilise pas building ?)

building:material=dry_stone (même question, où mettre dry_stone si on n'utilise 
pas building ?)

description=abri de berger en pierres sèches

wikipedia=fr:Cabane_en_pierre_sèche






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

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

[David Crochet]

Bonjour

Le 17/02/2020 à 12:14, Florimond Berthoux a écrit :
puis je me suis dit qu’en fait peu importe que ça soit de la pierre 
artificielle ou non, l’important c’est de préciser la surface du terrain.



Oui c'est vrai    , de tout façon "gravel" est toujours plus précis de 
"ground"


Cordialement

--
David Crochet


___
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 ?

[osm . sanspourriel]

Le 17/02/2020 à 17:20, Eric SIBERT via Talk-fr -
talk-fr@openstreetmap.org a écrit :


alors que pour ceux qui ont déjà un smartphone...


RTKGPS ?

Jean-Yvon



___
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 ?

[Eric SIBERT via Talk-fr]

Le 2020-02-17 13:55, marc marc a écrit :

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.

[...]

Là, je parle surtout de l'Afrique, la question initiale du fil de 
discussion. À Madagascar, j'ai l'impression d'être presque le seul 
contributeur à téléverser des traces GPS. La seule ville où il y a trop 
de traces, c'est celle de ma belle-famille. Sur les grands axes, ça 
devient illisible mais on peut aussi caler l'imagerie avec les axes 
secondaires.



Ou alors tu as un outil pour trouver la valeur médiane d'un ensemble de
traces ?


Non. À un moment donné, il y avait un outil comme ça avec les données 
strava. J'ai essayé avec les traces GPS des cyclistes en montagne mais 
ce n'était pas très concluant. Les cyclistes enregistrent beaucoup plus 
de points à la montée qu'à la descente, ce qui tirait latéralement les 
traces côté montée. Ensuite, l'algorithme coupait un oeu sauvagement les 
virages.





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


Oui mais beaucoup plus cher, un facteur limitant dans certains coins 
d'Afrique.


La solution avec deux F9P va couter 800 € (pour une portée de 35 km). On 
pourrait imaginer de travailler en mono-fréquence avec une puce Neo-M8M 
pour une centaine d'euros par récepteur et une portée limitée à 10 km.


Alors que pour ceux qui ont déjà un smartphone...

Eric


___
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

[osm . sanspourriel]

Si je résume la discussion on peut se mettre d'accord sur :
- le fait que le numéro de sortie doit être dans et uniquement dans le
champ ref.
- le fait que le pseudo-nom de la sortie (en général le nom de la rue
dans laquelle débouche la sortie, quelques fois un grand équipement) est
stocké dans name et que c'est la seule information qui y figure.
(éventuellement utiliser les alt_name, old_name...).
- le fait que le nom de la station correspondante se retrouve via la
(une ?) relation stop_area dans laquelle figure la station et donc son nom.

Si tu ne vois pas d'objection, tu peux y aller.

Pour les stations à sortie unique met-on aucun nom ou le nom de la
station ? Je ne mettrais pas de nom. On peut les laisser de côté le
temps de se mettre d'accord.

Jean-Yvon

Le 17/02/2020 à 16:17, Sébastien Hinderer -
sebastien.hinde...@ens-lyon.org a écrit :

Re,

Juste pour être ^sur sur un point:

marc marc (2020/02/17 15:07 +):

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)

OK. Et est-ce que du ocup je peux enlever le chiffre de name?


- le nom de la station n'est pas le nom de l'arrêt

Aussi OK et du coup, même question, est-ce que je peux enlever le nom de
la station du name associé à la bouche?

Sébastien.

___
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

[Sébastien Hinderer]

Re,

Juste pour être ^sur sur un point:

marc marc (2020/02/17 15:07 +):
> 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)

OK. Et est-ce que du ocup je peux enlever le chiffre de name?

> - le nom de la station n'est pas le nom de l'arrêt

Aussi OK et du coup, même question, est-ce que je peux enlever le nom de
la station du name associé à la bouche?

Sébastien.

___
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

[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)

  * 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.
> 
> 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

[Sébastien Hinderer]

Rebonjour,

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)
> >>
> >>  * 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.

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.

> 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?

> a mon avis, on ne sait pas tout faire en même temps.

Certes et ce n'set sans doute pas un problème.

> 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.

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.

Sébastien.

___
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

[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] Version FR du sticker "I Love OpenStreetMap"

[deuzeffe]

<3

Le 17/02/2020 à 13:21, Vincent Bergeot a écrit :

Le 17/02/2020 à 00:19, Vincent Privat a écrit :

Hello,
J'ai récupéré à GeoFabrik quelques stickers "I Love OpenStreetMap":
https://wiki.openstreetmap.org/wiki/Logos#I_love_OpenStreetMap

J'aime beaucoup le design, du coup je propose une version FR:
https://wiki.openstreetmap.org/wiki/File:Sticker_design_-FR-_J%27adore_OpenStreetMap.png 



Vous en pensez quoi ?


du bien, merci

j'ai fait un test (mais graphisme et moi bo ) avec le coeur (voir 
pj) pour voir.


à voir mais sinon favorable à la version que tu proposes pour en avoir 
au sotm-fr effectivement


à plus



___
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

[Sébastien Hinderer]

Bonjour Jean-Yvon et merci beaucoup pour ton message!

osm.sanspourr...@spamgourmet.com (2020/02/17 15:02 +0100):
> Par contre certaines bouches ont des "name" qui sont ceux de la
> station. :-(

Je peux éventuellement le concevoir si une station n'a qu'une seule
bouche de sortie comme Dugommier par exemple. Je ne dis pas que c'est
idéal, mais je peux imaginer donner du sens à ça.

> Sur Nuremberg, name c'est le nom de la destination (la rue sur laquelle
> on débouche).

C'est ce que je voudrais.

> N. B.  : j'ai regardé les utilisations de destination, en fait c'est moi
> qui avais introduit ça pour virer le gloubiboulga de RB94 (maintenant
> PARIS SUD) et ne laisser que la rue de destination en name.

Je plussoie ça.

> Exemple d'historique :
> https://www.openstreetmap.org/node/321920997/history
> 
> Pierre met le nom de la station Place d'Italie
> Noémie met station, numéro et destination en un : Place d'Italie -
> sortie 1 - Boulevard Auguste Blanqui
> RB94 "change certaines choses" et remplace le nom de la station par les
> références des lignes de bus : Bus 27 47 57 67 83 N15 N22 Sortie 1
> Boulevard Auguste Blanqui
> Bibi fait le ménage et dégage les bus dans la clé destination et
> supprime les infos dupliquées, ça devient : Boulevard Auguste Blanqui

Exactement ce vers quoi j'aimerais tendre, oui. Je me propose pour faire
ce genre de travail de façon systématique, je voudrais juste un GO. :)

> Et revoici RB94, devenu PARIS SUD suite à son blocage définitif, qui
> remet le bordel : (Place d'Italie) Sortie 1 Boulevard Auguste Blanqui

Oh non :(

> Pourquoi faire compliqué quand on peut fait inextricable ? Ce nœud fait
> partie de 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?

Sébastien.

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

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

[deuzeffe]

Bonjour,

Je me permets d'abonder dans le sens d'Arnaud et de préciser à Marcx2 
que oui, "c'est un type précis d'abris en pierre sèches par ex 
architecture particulière différentes des autres"


Arnaud, est-ce que vous vous êtes déjà "attaqués" aux glacières (il y en 
avait plein plein plein dans les Basses^WAlpes-de-Haute-Provence) ?


--
deuzeffe, loin de son pays :/

Le 17/02/2020 à 13:27, Arnaud Champollion a écrit :

Le 17/02/2020 à 13:21, Jacques Lavignotte a écrit :

https://fr.wikipedia.org/wiki/Borie

 on voit que selon que l'on est :

- à l'est de la vallée du Rhône une « borie » est une cabane de de 
berger (provence), 



Dans le cas présent, il s'agit sans aucune hésitation de cabanes de 
berger, et on est bien à l'est de la vallée du Rhône.




___
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

[osm . sanspourriel]

Le 17/02/2020 à 12:19, Stéphane Péneau - stephane.pen...@wanadoo.fr a
écrit :


Le 17/02/2020 à 09:19, Christian Quest a écrit :


Le fait qu'elle soit reliée à la station (stop_area) donne la
première indication, et le fait qu'elle porte un
nom/numéro/destination donne la seconde.

C'est ce qui rend inutile le nom de la station dans l'entrée.


Le 17/02/2020 à 11:19, osm.sanspourr...@spamgourmet.com a écrit :


D'une manière générale les bouches n'ont pas de nom, sauf peut-être
certaines entrées monumentales ayant leur propre page Wikipédia par
exemple.


Bah alors, elles ont un nom ou pas ?

Je me trompe peut-être, mais je pense que si on s'amuse a supprimer
les "name" sur les bouches de métro/rer/train, ça ne va pas plaire à
tout le monde.


Est-ce la question ?

Un contributeur (voir dessous), malgré l'avis unanime des contributeurs,
mettait tout dedans : nom de la station, numéro de la sortie,
destination de la sortie, lignes de bus à la sortie.

Bref un guide touristique dans le "nom".

Donc non ça ne va pas plaire à tout le monde.


Ici tout simplement :
noname=yes
destination=Rue Van Gogh
ref=13


"destination" sur un noeud, ça ne fonctionne pas. C'est fait pour être
utilisé sur un way.


C'est fait pour, on est d'accord.

Ça ne veut pas dire qu'on ne peut étendre le modèle (ou pas, je ne dis
pas que j'ai raison, c'est une base de discussion d’ailleurs jusqu'à
présent j'ai utilisé name - description aussi, mais pour autre chose,
voir ci-dessous).

Sur Berlin les numéros/lettres de sorties sont sur ref. Bien.

Par contre certaines bouches ont des "name" qui sont ceux de la station. :-(

Sur Nuremberg, name c'est le nom de la destination (la rue sur laquelle
on débouche).

N. B.  : j'ai regardé les utilisations de destination, en fait c'est moi
qui avais introduit ça pour virer le gloubiboulga de RB94 (maintenant
PARIS SUD) et ne laisser que la rue de destination en name.

Exemple d'historique :
https://www.openstreetmap.org/node/321920997/history

Pierre met le nom de la station Place d'Italie
Noémie met station, numéro et destination en un : Place d'Italie -
sortie 1 - Boulevard Auguste Blanqui
RB94 "change certaines choses" et remplace le nom de la station par les
références des lignes de bus : Bus 27 47 57 67 83 N15 N22 Sortie 1
Boulevard Auguste Blanqui
Bibi fait le ménage et dégage les bus dans la clé destination et
supprime les infos dupliquées, ça devient : Boulevard Auguste Blanqui
Et revoici RB94, devenu PARIS SUD suite à son blocage définitif, qui
remet le bordel : (Place d'Italie) Sortie 1 Boulevard Auguste Blanqui

Pourquoi faire compliqué quand on peut fait inextricable ? Ce nœud fait
partie de 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.

Jean-Yvon

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

Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

[Vincent Bergeot]

Le 17/02/2020 à 13:59, osm.sanspourr...@spamgourmet.com a écrit :


J' et le cœur ❤️ devrait être alignés.

nouvelle version / 
https://nextcloud.openstreetmap.fr/index.php/s/td3eRcoBp6bwJk8


J'aurais augmenté le contraste à l'intérieur de la loupe pour rendre 
les 011010 un peu plus lisibles.



cela dépasse mes compétences

le fichier gimp 
https://nextcloud.openstreetmap.fr/index.php/s/wxNqdLtP8ZZZ8Zp


c'est du bricolage, sans doute qu'il faudra le reprendre pour que cela 
soit vraiment utilisable !





Jean-Yvon

Le 17/02/2020 à 13:21, Vincent Bergeot - vinc...@bergeot.org a écrit :

Le 17/02/2020 à 00:19, Vincent Privat a écrit :

Hello,
J'ai récupéré à GeoFabrik quelques stickers "I Love OpenStreetMap":
https://wiki.openstreetmap.org/wiki/Logos#I_love_OpenStreetMap

J'aime beaucoup le design, du coup je propose une version FR:
https://wiki.openstreetmap.org/wiki/File:Sticker_design_-FR-_J%27adore_OpenStreetMap.png 



Vous en pensez quoi ?


du bien, merci

j'ai fait un test (mais graphisme et moi bo ) avec le coeur (voir 
pj) pour voir.


à voir mais sinon favorable à la version que tu proposes pour en 
avoir au sotm-fr effectivement


à plus



___
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



--
Vincent Bergeot

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

Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

[osm . sanspourriel]

J' et le cœur ❤️ devrait être alignés.

J'aurais augmenté le contraste à l'intérieur de la loupe pour rendre les
011010 un peu plus lisibles.

Jean-Yvon

Le 17/02/2020 à 13:21, Vincent Bergeot - vinc...@bergeot.org a écrit :

Le 17/02/2020 à 00:19, Vincent Privat a écrit :

Hello,
J'ai récupéré à GeoFabrik quelques stickers "I Love OpenStreetMap":
https://wiki.openstreetmap.org/wiki/Logos#I_love_OpenStreetMap

J'aime beaucoup le design, du coup je propose une version FR:
https://wiki.openstreetmap.org/wiki/File:Sticker_design_-FR-_J%27adore_OpenStreetMap.png


Vous en pensez quoi ?


du bien, merci

j'ai fait un test (mais graphisme et moi bo ) avec le coeur (voir
pj) pour voir.

à voir mais sinon favorable à la version que tu proposes pour en avoir
au sotm-fr effectivement

à plus



___
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] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[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 ?

[Eric SIBERT via Talk-fr]

faut-il laisser tourner une appli utilisant
le gps en permanence ?


Oui. OSMTracker par exemple, surtout que ma recommandation première pour 
caler les photos satellites est d'enregistrer un maximum de trace GPS 
sur les zones de travail.




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 ?


Plus il y a de satellites, plus on récupère les infos rapidement. Sinon, 
on risque de travailler avec des informations incomplètes, voir 
périmées. De plus, en captant bien les satellites, le récepteur va, pour 
chaque satellite, en plus de la mesure de distance, récupérer la phase 
(le nombre de cycles de l'onde porteuse entre deux mesures de distance 
successives). La phase est très précise car elle est mesurée à une 
fraction de longueur d'onde près (longueur d'onde du signal GPS=20 cm). 
Ça permet de lisser efficacement la position dans le temps. Si on coupe 
la réception, on repart plus ou moins à zéro. Dans la véranda, collée à 
la maison et avec une structure métallique, ça risque de ne pas être top 
car on ne voit pas tous les satellites. Pour la voiture, un parebrise 
athermique risque aussi de poser problème. C'est néanmoins ce que je 
fais. Dès que j'arrive à la voiture, je mets en route le GPS sur le 
tableau de bord, le plus loin possible sous le parebrise. Ensuite, je 
charge les enfants, les bagages et tout...


Eric


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

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

[Arnaud Champollion]

Le 17/02/2020 à 13:21, Jacques Lavignotte a écrit :

https://fr.wikipedia.org/wiki/Borie

 on voit que selon que l'on est :

- à l'est de la vallée du Rhône une « borie » est une cabane de de 
berger (provence), 



Dans le cas présent, il s'agit sans aucune hésitation de cabanes de 
berger, et on est bien à l'est de la vallée du Rhône.




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

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

[Jacques Lavignotte]

Borie, bòria, borde

Si on lit un peu avant l'article WKP

https://fr.wikipedia.org/wiki/Borie

 on voit que selon que l'on est :

- à l'est de la vallée du Rhône une « borie » est une cabane de de 
berger (provence),


- à l'ouest de la vallée du Rhône

	- une ferme disposant d'un territoire agricole conséquent (bòria dans 
l'Aude et le Gard)


	-une grange de dimension telle que l'on peut y entrer une charette de 
foin et stocker (borde dans la Gascogne)


Mettez quelques régionalistes sur le cas..


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] Nettoyage Enedis / GRDF

[Quentin Salles]

Bonjour,
J'ai effectué la modification des clés ERDF et ENEDIS sur toute la région
Occitanie. N'étant pas sur de ma contribution, voici ce que j'ai fait :
- Les postes de transformation basculent vers Enedis après vérification sur
le site de l'agence ORE
- Les câbles électriques en surface sont divisés en 2 parties :
-- Les "minor_line" ont comme opérateur Enedis
-- Les autres (voltage=63000) ont comme opérateur RTE.
J'espère ne pas m'être trompé sur mes contributions.

Je n'ai pas réalisé de bascule EDF vers Enedis vu que je ne suis pas assez
calé pour réaliser ces modifications.

Bonne journée

Quentin
___
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 ?

[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

[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] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Eric SIBERT via Talk-fr]

Bonjour,

En complément de mon précédent message et de celui de Stéphane.

Pour l'utilisation d'un récepteur GPS autonome ou d'un smartphone, on le 
met en route à l'avance et on le laisse sur un point dégagé pendant 
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, 
paramètres de la ionosphère...).


Pour la future campagne à Madagascar, je prévois de partir avec deux 
enregistreurs F9P. Pour les périodes plus ou moins en fixe, une dans un 
Parc National, l'autre dans une ville, je prévois de laisser un 
récepteur en fixe pour la durée du séjour alors que l'autre servira aux 
relevés sur le terrain. De retour en France, un calcul PPP sur les 
stations fixes temporaires doit permettre de descendre à 10 cm de 
précision sur ces stations. Ensuite, on fait un calcul différentiel 
entre la station fixe et la station mobile qui se déplace à quelques 
kilomètres de là, avec une incertitude de 1 cm + (1 mm par kilomètre 
d'écart). L'usage de deux récepteurs/antennes identiques permet de 
limiter certains biais de calcul.


Eric


___
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

[Stéphane Péneau]

Le 17/02/2020 à 11:19, osm.sanspourr...@spamgourmet.com a écrit :


N. B. : curieux une bouche de métro au niveau -2. Non accessible depuis
l'arrêt de bus ?

Il y a un escalier, et le rideau métallique qui permet de fermer 
l'entrée est en bas de cet escalier.


il y a des photos sur Mapillary : 
https://www.mapillary.com/map/im/SVmAQGYC3wBDC8l7rxBwtg



Stf



___
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

[Stéphane Péneau]

Le 17/02/2020 à 09:19, Christian Quest a écrit :


Le fait qu'elle soit reliée à la station (stop_area) donne la première 
indication, et le fait qu'elle porte un nom/numéro/destination donne 
la seconde.



Le 17/02/2020 à 11:19, osm.sanspourr...@spamgourmet.com a écrit :


D'une manière générale les bouches n'ont pas de nom, sauf peut-être
certaines entrées monumentales ayant leur propre page Wikipédia par 
exemple.



Bah alors, elles ont un nom ou pas ?

Je me trompe peut-être, mais je pense que si on s'amuse a supprimer les 
"name" sur les bouches de métro/rer/train, ça ne va pas plaire à tout le 
monde.




Ici tout simplement :
noname=yes
destination=Rue Van Gogh
ref=13

"destination" sur un noeud, ça ne fonctionne pas. C'est fait pour être 
utilisé sur un way.



Le 17/02/2020 à 09:19, Christian Quest a écrit :



Faire intervenir un autre type de relation (destination_sign) ne 
simplifie pas la réutilisation et de moins en moins KISS ;)



Coquin ! :-)

Ce type de relation existe pour les cas complexes que ne peut pas 
décrire seul le tag "destination". Lorsqu'on mélange "grandes gares", 
"indoor" et représentation surfacique, on se retrouve rapidement obligé 
de les utiliser.



Stf


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

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

[Jacques Lavignotte]

Le 17/02/2020 à 12:03, marc marc a écrit :

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.


Ici ça me parait clair (et conforme à mon souvenir, c'est dire la 
validité ;) :


https://fr.wikipedia.org/wiki/Borie#Borie_au_sens_de_%C2%AB_cabane_en_pierre_s%C3%A8che_%C2%BB

J.
--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

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

[Florimond Berthoux]

Je me suis fait la même réflexion, puis je me suis dit qu’en fait peu
importe que ça soit de la pierre artificielle ou non, l’important c’est de
préciser la surface du terrain.
D’ailleurs le wiki dit :
«surface ground : No special surface, the ground itself has marks of human
or animal usage. This value gives only a rough description; if possible,
use a more precise value such as grass, clay, sand, earth, gravel or
pebblestone.»

https://wiki.openstreetmap.org/wiki/Key:surface

Le lun. 17 févr. 2020 à 12:01,  a écrit :

> Bonjour
>
> - Mail original -
> de même, par contre c’est un surface=gravel, ce n’est pas de la terre,
> c’est un chemin empierré.
> - Mail original -
>
> C'est là que c'est pas facile à déterminer.
> J'ai l'impression que la pierre que l'on voit est de l'affleurement, c'est
> a dire que la roche apparait à la surface du sol et qu'il n'y a pas eu
> d'ajout artificiel de pierre
> En parcourant le chemin, le ravinage a emmené toute la terre et à donc
> laissé apparent la pierre, d'où mon "ground"
>
> Cordialement
>
> --
> David Crochet
>
> ___
> 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

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

[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] Bon usage de tracktype

[david . crochet]

Bonjour

- Mail original -
de même, par contre c’est un surface=gravel, ce n’est pas de la terre, c’est un 
chemin empierré. 
- Mail original -

C'est là que c'est pas facile à déterminer.
J'ai l'impression que la pierre que l'on voit est de l'affleurement, c'est a 
dire que la roche apparait à la surface du sol et qu'il n'y a pas eu d'ajout 
artificiel de pierre
En parcourant le chemin, le ravinage a emmené toute la terre et à donc laissé 
apparent la pierre, d'où mon "ground"

Cordialement

-- 
David Crochet

___
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

[Sébastien Hinderer]

Bonjour à tous,

Tout d'abord un grand merci à chacun pour vos contributions, toutes
hyper intéressantes à lire. Je n'ai pas encore pris le temps d'y
répondre, non pas par manque d'intérêt, loin s'en faut, mais parce que
j'aimerais d'abord essayer de dépouiller et d'avancer, pour pouvoir
apporter des éléments concrets et précis et pas rester dans du blabla
vague et général.

L'une des choses qui ne semble pas complètement tranchée, c''est de
savoir où on met le "nom" de la bouche, plus précisément si on le met
dans name ou dans destination. J'ai vu les deux avis exprimés et, pour
ma part, je n'en ai pas vraiment, en tout cas pas d'opinion tranchée.
Tout ce qui m'importe est qu'une décision soit prise, afin que je puisse
commencer le travail d'homogénéisation des données qui sont dans les
noeuds (il y en a tout de même 1188 à vérifier, au moins!).

Je fais juste une observation: mettre le "nom" ou la "description", ou
la "destination", dans name semble être la solution la plus conservative
par rapport aux pratiques en vigueur actuellement. Je ne sais pas si
c'est un argument suffisant pour justifier que c'est ainsi qu'il faut
faire, mais j'imagine qu'on peut au moins le prendre en considération.
Si on devait mettre le contenu de name dans destination, d'une part ça
ferait beaucoup de noeuds à modifier, d'autre part il faudrait voir où
on met ce qui est dans destination actuellement.

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

Une belle journée à tous et à bientôt pour d'autres éléments de réponse,

Sébastien.

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

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

[Arnaud Champollion]

Bonjour,

La question est à la fin du message.

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


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

C'est assez suivi semble-t-il, si l'on suit le lien overpass donné.


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


historic=shelter
building:loc=borie
building:material=dry_stone
description=borie
historic=yes
shelter_type=basic_hut


Là JOSM me prévient que ce n'est pas norla d'avoir un shelter_type sans 
amenity=shelter.


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


Ce qui donne :


amenity=shelter
building:loc=borie
building:material=dry_stone
description=borie
historic=yes
shelter_type=basic_hut


Une poignée de bories ont ainsi été ajoutés par ses soins.

Donc la question : je voudrais savoir si on a bien fait de mettre 
amenity=shelter comme le préconise JOSM, ou s'il vaut mieux suivre 
l'exemple de Garrigues avec historic=shelter.


Par ailleurs d'autres bories ont visiblement déjà été cartographiés par 
des contributeurs, avec soit des simples noeuds (ou même polygones) en 
name=borie, soit des historic=archaeological_site + name=borie.





___
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

[osm . sanspourriel]

+1 avec Christian.

Surtout on parle de *sorties*, destination fait le boulot.

Quand on parle des *entrées*, la destination (ici le pseudo nom) c'est
la station.

Si sur une carte vous voyez des bouches de métro 1,2, 3 autour de la
station X, si vous entrez dans une de ces bouches, où allez-vous ?

Gare de Lyon n'est jamais le nom de la bouche.

D'une manière générale les bouches n'ont pas de nom, sauf peut-être
certaines entrées monumentales ayant leur propre page Wikipédia par exemple.

Ici tout simplement :
noname=yes
destination=Rue Van Gogh
ref=13

N. B. : curieux une bouche de métro au niveau -2. Non accessible depuis
l'arrêt de bus ?

KISS

Le 17/02/2020 à 09:19, Christian Quest - cqu...@openstreetmap.fr a écrit :

Le 14/02/2020 à 15:56, Stéphane Péneau a écrit :

Une partie des bouches portent des indications différentes selon si
on entre ou sort du métro.
Pour se conformer à cette situation, tout en cartographiant les zones
intérieures en surfacique, on avait utilisé les relations
destination_sign.
Exemple à la gare de lyon :
https://www.openstreetmap.org/node/4086374120
Cette bouche porte le nom "Gare de Lyon" lorsqu'on vient de
l'extérieur, et "Sortie Rue Van Gogh" lorsqu'on sort.
Et sa relation destination_sign :
https://www.openstreetmap.org/relation/10054778

Stf


C'est normal vu qu'une bouche de métro est un point de passage pour
soit aller vers la station et prendre le métro, soit pour sortir de la
station et aller vers l'extérieur si possible dans une direction
donnée et donc la différencier des autres pour faire un choix.

Le fait qu'elle soit reliée à la station (stop_area) donne la première
indication, et le fait qu'elle porte un nom/numéro/destination donne
la seconde.

Faire intervenir un autre type de relation (destination_sign) ne
simplifie pas la réutilisation et de moins en moins KISS ;)




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

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

[Quentin Salles]

Bonjour François,

Merci pour cet ajout. Je retrouve les cas que j'ai rencontré dans ma
commune, notamment les postes de distribution privés
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de Hack Weekend à Toulouse, 4 et 5 avril

[Frédéric Rodrigo]

Bonjour,

La date pour ce hack weekend est donc fixé au weekend du 4 et 5 avril.


Inscrivez-vous sur la page du wiki si vous envisagez de venir :

https://wiki.openstreetmap.org/wiki/Toulouse_Hack_Weekend_April_2020


Vous pouvez venir avec un sujet sur lequel vous souhaitez avancer, ou 
participer à des sujets proposés par d'autres. L'asso OSM-FR à aussi 
besoin de coups de mains sur des besoins techniques par exemple de la 
maintenance sur uMap.



Frédéric.




Le 11/02/2020 à 15:05, Frédéric Rodrigo a écrit :

J'ai créer un framadate pour trouver le weekend qui convient le mieux

https://framadate.org/lugSTfQkmgibtAL9

l'idée est d’arrêter une date assez vite.

Frédéric


Le 07/02/2020 à 22:29, Vincent Privat a écrit :

Très bon choix de ville, je viens ! :D

Le ven. 7 févr. 2020 à 16:38, Christine Karch > a écrit :


    Idée géniale :)

    On pourrait demander l'Asso de supporter le coût du transport ...


    Am 07.02.20 um 16:28 schrieb PanierAvide:
    > Bonjour,
    >
    > Ce serait sympa en effet, à voir selon la date et le coût du
    transport
    > car Rennes c'est pas à côté.
    >
    > Cordialement,
    >
    > Adrien P.
    >
    > Le 07/02/2020 à 15:36, Vincent de Château-Thierry a écrit :
    >> Bonjour,
    >>
    >>> De: "Frédéric Rodrigo" mailto:fred.rodr...@gmail.com>>
    >>>
    >>> Avec mon employeur, Makina Corpus, je propose d'organiser une 
Hack

    >>> Weekend à Toulouse, sur le modèle de ce que fait par exemple
    >>> Geofabrik.
    >>> Il n'y a pas encore de date, mais l'idée est de le faire vers
    avril.
    >>> J'ai commencé à préparer une page sur le wiki pour cela:
    >>>
https://wiki.openstreetmap.org/wiki/Toulouse_Hack_Weekend_April_2020
    >>>
    >>> J'aurais aimé avoir vos retours sur cette proposition et 
notamment

    >>> pour
    >>> choisir une date.
    >> Bonne idée ça :)
    >>
    >> Tu lances un https://framadate.org/ pour trouver le bon WE ?
    >>
    >> vincent




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

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

[Florimond Berthoux]

Salut,

@rainerU ton interprétation est bonne un track c’est un chemin agricole ou
forestier peut importe sa qualité de revêtement.
Grade 1 = « Solid. Usually a paved or sealed surface. »

Le lun. 17 févr. 2020 à 09:11, David Crochet  a
écrit :

> Bonjour
>
> Le 17/02/2020 à 07:33, rainerU a écrit :
> >
> > https://www.openstreetmap.org/changeset/79978741
> >
> >
>
> Les 2 photo montre une piste en sol naturel pierreuse sans ajout de
> matière autre avec un passage de roue non végétabilité c'est :
>
> Highway=track + grade=2 + smoothness=bad + surface=ground
>

de même, par contre c’est un surface=gravel, ce n’est pas de la terre,
c’est un chemin empierré.


>
> Cordialement
>
> --
> David Crochet
>

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

Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

[Jacques Lavignotte]

Le 17/02/2020 à 09:53, Christian Quest a écrit :

J'aurai mis un coeur à la place du "love " ou "adore" ;)


+1

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

[Cédric Frayssinet]

Le 17/02/2020 à 09:53, Christian Quest a écrit :
> J'aurai mis un coeur à la place du "love " ou "adore" 

Je me suis fait exactement la même réflexion. Un cœur rouge pour donner
un peu de visuel et panache à l'ensemble :)

Cédric



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

Re: [OSM-talk-fr] Version FR du sticker "I Love OpenStreetMap"

[Christian Quest]

J'aurai mis un coeur à la place du "love " ou "adore" ;)


Le 17/02/2020 à 08:40, PanierAvide a écrit :


Salut,

+1, on en imprime pour le Sotm et les distribuer aux groupes locaux ? :-)

Cordialement,

Adrien P.
Le 17/02/2020 à 00:19, Vincent Privat a écrit :

Hello,
J'ai récupéré à GeoFabrik quelques stickers "I Love OpenStreetMap":
https://wiki.openstreetmap.org/wiki/Logos#I_love_OpenStreetMap

J'aime beaucoup le design, du coup je propose une version FR:
https://wiki.openstreetmap.org/wiki/File:Sticker_design_-FR-_J%27adore_OpenStreetMap.png

Vous en pensez quoi ?

Vincent


--
Christian Quest - OpenStreetMap France


___
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 ?

[Christian Quest]

Le 17/02/2020 à 01:37, Victor/tuxayo a écrit :

On 20-02-13 00:27, marc marc wrote:

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


Donc dans ce cas ça donnerait:
tourism=information
information=board
unsigned=board_type:surveillance
ou unsigned:board_type=surveillance ?



Pas pour moi, car ce n'est pas un panneau d'information touristique (ça 
a été dit ici) donc pas de tourism=information


Le wiki me semble clair sur le fait que tourism=information est destiné 
aux touristes... ce n'est pas le cas de ces panneaux.


La réutilisation de base s'appuie en général sur les tags de premier 
niveau et ne connaît pas forcément toutes les finesses et subtilité 
apportées par les autres tags.




Piste plus simple:

Après lecture du wiki de unsigned=*
https://wiki.openstreetmap.org/wiki/Key:unsigned

> This key is used to annotate the fact that there is no on-the-ground 
sign indicating this feature's name.


Ça semble assez approprié en cas de manque de panneau réglementaire 
qu'on puisse mettre "unsigned=yes", il suffit d'étendre un peu l'usage 
de unsigned a plus que des noms.
Donc ça donne bien envie de partir dessus, mais du coup pourquoi on 
mettrait pas directement "signed=no" ou "signed=yes" plutot? Ce serait 
plus direct, et ça éviterait les confusions et les doubles négations 
("unsigned=no" signifierait qu'il y a un panneau...).


Et ça éviterait la chaine:
tourism=information
information=board
board_type=surveillance


== Donc en résumé ==
Créer la page wiki pour documenter:
signed=yes
signed=no

qui indique qu'un objet porte un panneau sur lui.
Et dans la page wiki de man_made=surveillance préciser que c'est par 
rapport au panneau réglementaire dans les contextes où une telle 
réglementation existe.


Si ça vous semble pas trop mal, je peux ouvrir le sujet sur la liste 
tagging.


== alternative ==
Si signed=* est trop général et que c'est gênant:
camera:signed=yes
camera:signed=no


À++



Signaler sur l'objet camera que la surveillance est correctement 
signalée ou pas, me semble plus adapté, après pour le tag éviter la 
double négation est préférable.


--
Christian Quest - OpenStreetMap France


___
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 ?

[Christian Quest]

Les rôles label ne sont pas pris en compte par le rendu .fr et c'est 
sûrement pareil pour .org


Pourquoi ?

Parce que la transformation des données OSM en données pour les rendus 
ne permet pas de faire cela simplement.


Donc pour le rendu, seul le noeud place est utilisé.


Une relation type=boundary ? Mais ce n'est pas une frontière ou alors 
cela revient à considérer toute limite de zone comme une frontière... la 
lisière d'une forêt serait tout autant une "frontière" !


Dans l'exemple donné, on a un lotissement qui pourrait très bien se 
satisfaire d'un landuse=residential nommé.


Pourquoi avoir besoin d'un élément ponctuel pour mettre arbitrairement 
le nom à un endroit précis sur une carte ?


Si il n'y a plus la place pour ce libellé à cet endroit, le rendu n'a 
pas le droit de le déplacer dans le polygone ?



KISS !


Le 16/02/2020 à 19:12, Stéphane Péneau a écrit :

Le 16/02/2020 à 18:02, osm.sanspourr...@spamgourmet.com a écrit :


> Je suis le seul à trouver ça un peu tordu ?
Peut-être pas.

Mais en tous cas, moi ça ne me choque pas.

Si tu veux mélanger une notion surfacique et une notion ponctuelle, 
dans OSM la réponse c'est la relation. Après si tu dérives la notion 
ponctuelle à partir du surfacique, tu peux t'en passer. Mais ici le 
rendu ne tenant compte que des place sur les nœuds, tu n'y coupes pas.


Sauf à manquer d'une information.



Donc c'est tagger pour le rendu, non ?

Stf



Jean-Yvon

Le 16/02/2020 à 13:09, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
écrit :
Une relation pour délimiter un ensemble de 8 maisons ? Je suis le 
seul à trouver ça un peu tordu ?


Stf


Le 05/02/2020 à 21:58, osm.sanspourr...@spamgourmet.com a écrit :


https://www.openstreetmap.org/relation/10060749#map=19/47.78699/-3.48688

Le Prat et Les Jardins de Vitalis sont deux lotissements jointifs. 
Et tu pourrais les englober dans des place de plus haut niveau.


Ils font partie du landuse=residential de la zone agglomérée du 
bourg de Guidel.


On ne mélange pas l'utilisation (landuse) des dénominations (ici Le 
Prat et Les Jardins de Vitalis) qui ont leur vie propre si j'ose dire.


Jean-Yvon

Le 05/02/2020 à 21:26, Arnaud Champollion - 
arnaud.champoll...@linux-alpes.org a écrit :

Le 05/02/2020 à 21:23, pepilepi...@ovh.fr a écrit :


Pourquoi tu veux faire ça ? Si c'est juste pour le nommer il y a 
place=neighbourhood 
...


Bonne soirée,



Justement je ne veux pas le faire.

Je suis tombé dessus car il y a plusieurs zones mappées ainsi à 
Digne les Bains.


Je me suis dit que ça n'avait pas l'air normal, mais je voulais 
m'en assurer avant de supprimer ou remplacer par un tag plus adapté.




___
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




--
Ce message a été vérifié par *MailScanner* 
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

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


--
Christian Quest - OpenStreetMap France

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

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

[Christian Quest]

Le 14/02/2020 à 15:56, Stéphane Péneau a écrit :
Une partie des bouches portent des indications différentes selon si on 
entre ou sort du métro.
Pour se conformer à cette situation, tout en cartographiant les zones 
intérieures en surfacique, on avait utilisé les relations 
destination_sign.

Exemple à la gare de lyon :
https://www.openstreetmap.org/node/4086374120
Cette bouche porte le nom "Gare de Lyon" lorsqu'on vient de 
l'extérieur, et "Sortie Rue Van Gogh" lorsqu'on sort.

Et sa relation destination_sign :
https://www.openstreetmap.org/relation/10054778

Stf

C'est normal vu qu'une bouche de métro est un point de passage pour soit 
aller vers la station et prendre le métro, soit pour sortir de la 
station et aller vers l'extérieur si possible dans une direction donnée 
et donc la différencier des autres pour faire un choix.


Le fait qu'elle soit reliée à la station (stop_area) donne la première 
indication, et le fait qu'elle porte un nom/numéro/destination donne la 
seconde.


Faire intervenir un autre type de relation (destination_sign) ne 
simplifie pas la réutilisation et de moins en moins KISS ;)


--
Christian Quest - OpenStreetMap France


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

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

[David Crochet]

Bonjour

Le 17/02/2020 à 07:33, rainerU a écrit :


https://www.openstreetmap.org/changeset/79978741




Les 2 photo montre une piste en sol naturel pierreuse sans ajout de 
matière autre avec un passage de roue non végétabilité c'est :


Highway=track + grade=2 + smoothness=bad + surface=ground

Cordialement

--
David Crochet


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