[OSM-talk-fr] amenity=townhall et place=village à séparer ?

2016-02-10 Par sujet Nicolas Moyroud 

Bonjour à tous,

En faisant une petite analyse des mairies sur la France entière j'ai 
remarqué quelques cas particuliers de tags amenity=townhall et 
place=village sur le même noeud. Ça reste tout de même marginal (61 
noeuds sur 18402), mais je me demandais si c'était vraiment une bonne 
idée de faire ça. Le place=village pourrait éventuellement être déplacé 
par un contributeur (par exemple si il souhaite le placer plus au centre 
de la zone bâtie), ce qui aurait le très désagréable effet de bord de 
déplacer la mairie avec...
Du coup ce serait peut-être une bonne idée de séparer les tags sur 2 
noeuds différents, quitte à laisser les deux très proches pour les 61 
objets concernés.

Votre avis ?

Nicolas


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

Re: [OSM-talk-fr] amenity=townhall et place=village à séparer ?

2016-02-10 Par sujet Jérôme Seigneuret 
Pour moi la fusion n'a aucun intérêt le place étant plutôt situé au centre
de gravité de son emprise (même si elle est un peut flou dans certains cas)

Je pense que tes cas de saisie sont liés à l'usage d'autre bases (IGN) où
le nom de la commune était récupéré sur la localisation de la mairie.

Donc oui, en effet, quand les éléments sont sans rapport entre eux, il faut
autant que possible saisir deux objets. C'est ce qui est conseillé sur les
pratiques de saisie d'OSM.

Jérôme


Le 10 février 2016 à 16:35, Nicolas Moyroud  a écrit :

> Bonjour à tous,
>
> En faisant une petite analyse des mairies sur la France entière j'ai
> remarqué quelques cas particuliers de tags amenity=townhall et
> place=village sur le même noeud. Ça reste tout de même marginal (61 noeuds
> sur 18402), mais je me demandais si c'était vraiment une bonne idée de
> faire ça. Le place=village pourrait éventuellement être déplacé par un
> contributeur (par exemple si il souhaite le placer plus au centre de la
> zone bâtie), ce qui aurait le très désagréable effet de bord de déplacer la
> mairie avec...
> Du coup ce serait peut-être une bonne idée de séparer les tags sur 2
> noeuds différents, quitte à laisser les deux très proches pour les 61
> objets concernés.
> Votre avis ?
>
> Nicolas
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Doute sur le calage Bing/Cadastre

2016-02-10 Par sujet JB 

Le 09/02/2016 12:01, Tyndare a écrit :
Je ne sais pas ce qu'elle vaut dans ce coin mais en cas de doutes de 
callage j'ai tendance à faire confiance à la couche des traces Strava 
(en désactivant le zoom automatique dans JOSM pour zoomer plus que le 
fond qu'ils rendent disponible, et en affichant la couche plusieurs 
fois si il y a peu de points pour les rendre plus visibles)
J'apprécie aussi Strava dans les zones où les VTTistes passent, et 
regrette la faible visibilité et manque de zoom aux échelles de traçage.

Mais désactiver le zoom automatique, tu fais ça comment ?
JB.

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

Re: [OSM-talk-fr] amenity=townhall et place=village à séparer ?

2016-02-10 Par sujet Christian Quest 
Les séparer a un autre avantage... permettre d'avoir sur les rendus le nom
de la commune ET une icône pour la mairie... si on met tout au même endroit
c'est en général le nom de la commune qui gagne et on ne voit plus la
mairie ;)


Le 10 février 2016 à 17:02, Jérôme Seigneuret  a
écrit :

> Pour moi la fusion n'a aucun intérêt le place étant plutôt situé au centre
> de gravité de son emprise (même si elle est un peut flou dans certains cas)
>
> Je pense que tes cas de saisie sont liés à l'usage d'autre bases (IGN) où
> le nom de la commune était récupéré sur la localisation de la mairie.
>
> Donc oui, en effet, quand les éléments sont sans rapport entre eux, il
> faut autant que possible saisir deux objets. C'est ce qui est conseillé sur
> les pratiques de saisie d'OSM.
>
> Jérôme
>
>
> Le 10 février 2016 à 16:35, Nicolas Moyroud  a écrit :
>
>> Bonjour à tous,
>>
>> En faisant une petite analyse des mairies sur la France entière j'ai
>> remarqué quelques cas particuliers de tags amenity=townhall et
>> place=village sur le même noeud. Ça reste tout de même marginal (61 noeuds
>> sur 18402), mais je me demandais si c'était vraiment une bonne idée de
>> faire ça. Le place=village pourrait éventuellement être déplacé par un
>> contributeur (par exemple si il souhaite le placer plus au centre de la
>> zone bâtie), ce qui aurait le très désagréable effet de bord de déplacer la
>> mairie avec...
>> Du coup ce serait peut-être une bonne idée de séparer les tags sur 2
>> noeuds différents, quitte à laisser les deux très proches pour les 61
>> objets concernés.
>> Votre avis ?
>>
>> Nicolas
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] amenity=townhall et place=village à séparer ?

2016-02-10 Par sujet Jérôme Amagat 
C'est pas le nom de la commune, c'est le nom du village! ;)
Le nom de la commune n'apparaît pas sur les rendus ( en tout cas les
principaux)

Et je suis d'accord, les séparer c'est mieux. D'ailleurs les
nœud place=village ne devrai je pense n'être accrocher a rien. Ça m ai
arriver d'en séparer de route.


Le mercredi 10 février 2016, Christian Quest  a
écrit :

> Les séparer a un autre avantage... permettre d'avoir sur les rendus le nom
> de la commune ET une icône pour la mairie... si on met tout au même endroit
> c'est en général le nom de la commune qui gagne et on ne voit plus la
> mairie ;)
>
>
> Le 10 février 2016 à 17:02, Jérôme Seigneuret  > a écrit :
>
>> Pour moi la fusion n'a aucun intérêt le place étant plutôt situé au
>> centre de gravité de son emprise (même si elle est un peut flou dans
>> certains cas)
>>
>> Je pense que tes cas de saisie sont liés à l'usage d'autre bases (IGN) où
>> le nom de la commune était récupéré sur la localisation de la mairie.
>>
>> Donc oui, en effet, quand les éléments sont sans rapport entre eux, il
>> faut autant que possible saisir deux objets. C'est ce qui est conseillé sur
>> les pratiques de saisie d'OSM.
>>
>> Jérôme
>>
>>
>> Le 10 février 2016 à 16:35, Nicolas Moyroud > > a écrit :
>>
>>> Bonjour à tous,
>>>
>>> En faisant une petite analyse des mairies sur la France entière j'ai
>>> remarqué quelques cas particuliers de tags amenity=townhall et
>>> place=village sur le même noeud. Ça reste tout de même marginal (61 noeuds
>>> sur 18402), mais je me demandais si c'était vraiment une bonne idée de
>>> faire ça. Le place=village pourrait éventuellement être déplacé par un
>>> contributeur (par exemple si il souhaite le placer plus au centre de la
>>> zone bâtie), ce qui aurait le très désagréable effet de bord de déplacer la
>>> mairie avec...
>>> Du coup ce serait peut-être une bonne idée de séparer les tags sur 2
>>> noeuds différents, quitte à laisser les deux très proches pour les 61
>>> objets concernés.
>>> Votre avis ?
>>>
>>> Nicolas
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> 
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> 
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] amenity=townhall et place=village à séparer ?

2016-02-10 Par sujet Nicolas Moyroud 
Oui en effet Christian je n'avais pas pensé à ça car ... on ne taggue 
pas pour le rendu ! :-P

Mais là je pense qu'on peut dire que c'est une exception à la règle.
OK merci pour la confirmation, donc je vais faire de la séparation sur 
les 61 communes concernées.


Nicolas

Le 10/02/2016 22:09, Jérôme Amagat a écrit :

C'est pas le nom de la commune, c'est le nom du village! ;)
Le nom de la commune n'apparaît pas sur les rendus ( en tout cas les 
principaux)


Et je suis d'accord, les séparer c'est mieux. D'ailleurs les 
nœud place=village ne devrai je pense n'être accrocher a rien. Ça m ai 
arriver d'en séparer de route.



Le mercredi 10 février 2016, Christian Quest > a écrit :


Les séparer a un autre avantage... permettre d'avoir sur les
rendus le nom de la commune ET une icône pour la mairie... si on
met tout au même endroit c'est en général le nom de la commune qui
gagne et on ne voit plus la mairie ;)



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

Re: [OSM-talk-fr] amenity=townhall et place=village à séparer ?

2016-02-10 Par sujet Christian Quest 
Ces noeuds place=* servent plus ou moins de role de label pour les
relations définissant les limites des communes.

En fait tout ça n'est pas très cohérent, mais issu de l'historique et
surtout de la longue période où l'on avait ces noeuds mais pas encore les
limites des communes.

Ils ne servent pas qu'à ça, mais c'est quand même l'usage le plus courant.


Le 10 février 2016 à 22:24, Nicolas Moyroud  a écrit :

> Oui en effet Christian je n'avais pas pensé à ça car ... on ne taggue pas
> pour le rendu ! :-P
> Mais là je pense qu'on peut dire que c'est une exception à la règle.
> OK merci pour la confirmation, donc je vais faire de la séparation sur les
> 61 communes concernées.
>
> Nicolas
>
> Le 10/02/2016 22:09, Jérôme Amagat a écrit :
>
> C'est pas le nom de la commune, c'est le nom du village! ;)
> Le nom de la commune n'apparaît pas sur les rendus ( en tout cas les
> principaux)
>
> Et je suis d'accord, les séparer c'est mieux. D'ailleurs les
> nœud place=village ne devrai je pense n'être accrocher a rien. Ça m ai
> arriver d'en séparer de route.
>
>
> Le mercredi 10 février 2016, Christian Quest < 
> cqu...@openstreetmap.fr> a écrit :
>
>> Les séparer a un autre avantage... permettre d'avoir sur les rendus le
>> nom de la commune ET une icône pour la mairie... si on met tout au même
>> endroit c'est en général le nom de la commune qui gagne et on ne voit plus
>> la mairie ;)
>>
>
>
> ___
> 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] eaux intérieures (était Image of the week)

2016-02-10 Par sujet osm . sanspourriel 
Ça ne vaut pas encore le coin de l'Aber dans la presqu'ile de Crozon (*) 
pour la précision (par contre pour créer la relation soit il maîtrise 
QGis ou autre soit il a galéré).

http://www.openstreetmap.org/#map=15/48.2309/-4.4390
http://tile.openstreetmap.fr/?zoom=15=48.23094=-4.43548=B000FF

En théorie pour les plages un outil devrait permettre de la tracer et de 
la nommer bêtement et découper de part et d'autre de la ligne de côte 
(avec un tidal=yes en aval) et le nom porté par la relation qui compose 
les deux.

Ou plutôt sur un nœud ayant le rôle label: pas besoin de nouveau tag.
Bien sûr je parle d'endroit où la ligne de côte est une vraie ligne de côte.

Pour les lignes artificielles (embouchures) ça me dérange d'ailleurs 
d'avoir un natural=coastline.
Je proposerais bien un natural=virtual_coastline ou d'ajouter un 
virtual=yes.
Si et seulement si on ne souhaite pas remonter dans les estuaires le 
long du coef de 95.


Or le wiki précise :
/quand la législation locale définit un domaine maritime (*par exemple 
en France* les lois protégeant le littoral), on fera remonter les lignes 
de côtes assez haut dans le fleuve pour qu'elles bordent entièrement ce 
domaine maritime, même s'il y a un ouvrage d'art traversant l'estuaire 
plus bas en aval./


Donc on a maintenant du boulot (et la Laïta qui est la partie maritime 
de l'Ellé cesse d'être une riverbank ? et devient natural 
=water 
, tidal=yes ?)


Des objections ?

Jean-Yvon
(*) vous avez vu, l'ile a perdu son accent circonflexe, pour le nom de 
l'Île-de-Sein il faut un décret ou on doit mettre name=Ile-de-Sein et 
old_name=Île-de-Sein ?). Autre solution sur tout fr:name remplacer à 
l'affichage les Î par des I.




Le 10/02/2016 22:43, Eric Debeau - eric.deb...@gmail.com a écrit :

Bonsoir

C'est justement l'extraction des données de OSM et le contour de 
Lannion-Tregor Communaté pour réaliser ce support que j'ai vu des 
données qui m'ont interpellé.


Sur le GR34 qui passe sur une zone en dehors de la terre ferme, je ne 
suis pas surpris. J'irai vérifier sur le terrain, mais je pense que 
c'est probable à cause justement des constructions et malheureusement 
le respect de la servitude de passage des piétons le long du littoral 
n'est pas toujours respecté, mais en Bretagne, on n'a pas trop à se 
plaindre par rapport à d'autres régions.
Je trouve que ce serait intéressant de montrer les zones de servitudes 
de passage du littoral sur OSM.


C'est vrai qu'il manque beaucoup d'information sur l'estran sur OSM. 
J'ai vu une avancée intéressante du coté de Penvenan:

http://www.openstreetmap.org/relation/5449871

Avec les informations des Orthophotos de Geolittoral, on doit pouvoir 
indiquer les zones découvertes. Après, il y a du boulot pour 
distinguer les rochers, de la vase, du sable, des galets...


J'ai regardé sur la France, il y a seulement 192 objets avec tidal=yes

Sur les plages, je pense qu'il manque un tag représentant l'ensemble 
de la plage au dessus en en dessous de la ligne de cote. Le nom d'une 
plage ne fait pas de différence entre ces 2 parties et pour l'instant 
il faut ajouter le champ name dans les 2 parties.


Eric

2016-02-10 1:31 GMT+01:00 >:


Tu veux dire le chemin E9 dont certains ont déposé pour la partie
française GR 34 ? ;-).
Elles sont effectivement là en dehors de la terre ferme, c'est un
fait.
Le problème ici n'est pas tant tidal=sand ou beach mais l'absence
de tag qui fait penser à la pleine mer.
Très clairement là, le chemin passe sur un endroit recouvert d'eau
à marée haute ordinaire.

Enfin le vrai problème c'est que l'on ne fait pas respecter la
servitude littorale mais c'est un autre sujet.

N. B. : concrètement, est-ce que tu penses :

http://mc.bbbike.org/mc/?lon=-3.505597=48.825301=18=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=limite%20de%20la%20plage%20?
Ça ne me choque pas mais la différence c'est plus natural=sand au
dessus (d'un point de vue altimétrique, au sud ici) et au nord
c'est plutôt de la vase.
Ne mettre que beach dans la partie de coef supérieur à 100 va
minimiser les plages, certes.
Mais que le piéton sache qu'il peut être coincé par la marée me
semble plutôt une précision utile. Pas sûr que le trait de côte
suffise.
Mettrais-tu un tidal=yes ?

Alors près du lieu de vacances d'Antoine (pour ceux qui ont suivi) :

http://mc.bbbike.org/mc/?lon=-4.430902=48.231103=18=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=passage%20du%20sentier%20:%20tidal%20:%20yes

La carte y est plus précise.
Que voit-on :
- osm fr : les sols marins sont massacrés (la mer envahit tout y
compris les beach).
- osm : le gué (fjord=yes) est rendu comme un chemin ordinaire.

Re: [OSM-talk-fr] Image of the week

2016-02-10 Par sujet Eric Debeau 
Bonsoir

C'est justement l'extraction des données de OSM et le contour de
Lannion-Tregor Communaté pour réaliser ce support que j'ai vu des données
qui m'ont interpellé.

Sur le GR34 qui passe sur une zone en dehors de la terre ferme, je ne suis
pas surpris. J'irai vérifier sur le terrain, mais je pense que c'est
probable à cause justement des constructions et malheureusement le respect
de la servitude de passage des piétons le long du littoral n'est pas
toujours respecté, mais en Bretagne, on n'a pas trop à se plaindre par
rapport à d'autres régions.
Je trouve que ce serait intéressant de montrer les zones de servitudes de
passage du littoral sur OSM.

C'est vrai qu'il manque beaucoup d'information sur l'estran sur OSM. J'ai
vu une avancée intéressante du coté de Penvenan:
http://www.openstreetmap.org/relation/5449871

Avec les informations des Orthophotos de Geolittoral, on doit pouvoir
indiquer les zones découvertes. Après, il y a du boulot pour distinguer les
rochers, de la vase, du sable, des galets...

J'ai regardé sur la France, il y a seulement 192 objets avec tidal=yes

Sur les plages, je pense qu'il manque un tag représentant l'ensemble de la
plage au dessus en en dessous de la ligne de cote. Le nom d'une plage ne
fait pas de différence entre ces 2 parties et pour l'instant il faut
ajouter le champ name dans les 2 parties.

Eric

2016-02-10 1:31 GMT+01:00 :

> Tu veux dire le chemin E9 dont certains ont déposé pour la partie
> française GR 34 ? ;-).
> Elles sont effectivement là en dehors de la terre ferme, c'est un fait.
> Le problème ici n'est pas tant tidal=sand ou beach mais l'absence de tag
> qui fait penser à la pleine mer.
> Très clairement là, le chemin passe sur un endroit recouvert d'eau à marée
> haute ordinaire.
>
> Enfin le vrai problème c'est que l'on ne fait pas respecter la servitude
> littorale mais c'est un autre sujet.
>
> N. B. : concrètement, est-ce que tu penses :
>
> 
> http://mc.bbbike.org/mc/?lon=-3.505597=48.825301=18=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=limite%20de%20la%20plage%20
> ?
> Ça ne me choque pas mais la différence c'est plus natural=sand au dessus
> (d'un point de vue altimétrique, au sud ici) et au nord c'est plutôt de la
> vase.
> Ne mettre que beach dans la partie de coef supérieur à 100 va minimiser
> les plages, certes.
> Mais que le piéton sache qu'il peut être coincé par la marée me semble
> plutôt une précision utile. Pas sûr que le trait de côte suffise.
> Mettrais-tu un tidal=yes ?
>
> Alors près du lieu de vacances d'Antoine (pour ceux qui ont suivi) :
>
> 
> http://mc.bbbike.org/mc/?lon=-4.430902=48.231103=18=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=passage%20du%20sentier%20:%20tidal%20:%20yes
>
> La carte y est plus précise.
> Que voit-on :
> - osm fr : les sols marins sont massacrés (la mer envahit tout y compris
> les beach).
> - osm : le gué (fjord=yes) est rendu comme un chemin ordinaire.
>
> Dézoomons au niveau 15 :
>
> 
> http://mc.bbbike.org/mc/?lon=-4.436395=48.22783=16=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=rocher%20visible%20par%20coef%20proche%20de%20100
>
> Vous voyez un rocher visible par coef proche de 100 (non mappé) et une
> plage qui correspond grosso-modo à la mi-marée.
> Au-delà il faudrait du tidal=yes sur l'essentiel de la partie sableuse.
>
> Thomas dit ce que dit le wiki.
> Tu veux aller au delà.
>
> À quel niveau arrêter la plage ? Mi-marée ? Si tu prends autre chose que
> la ligne de côte c'est à peu près tout ce que tu peux faire de vérifiable.
> Mais quel intérêt ? L'isobathe du 0 terrestre ?
> Avec la ligne de côte tu vois s'il reste du sable à marée haute.
>
> Attention aussi au collage :
>
> 
> http://mc.bbbike.org/mc/?lon=-4.449497=48.23543=17=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=schiste
> Entre le trait de côte et la plage on ici (comme souvent) une falaise ou
> une ancienne falaise rabotée. Donc tidal=yes
>
>- natural=bare_rock
>
>
> Sinon on a l'impression que la plage commence en mer.
>
> Et si tu regarde Wikipédia la plage commence au niveau des dunes, peut
> être composée de galets : c'est juste une accumulation de matériaux en
> pente douce ! : 
> https://fr.wikipedia.org/wiki/Plage
> tidal=yes,

Re: [OSM-talk-fr] eaux intérieures (était Image of the week)

2016-02-10 Par sujet GarenKreiz 
Effectivement la suggestion d'utiliser une relation pour relier les
parties natural=beach et tidal=yes d'une même plage doit permettre de
suivre les consignes assez strictes du wiki tout en faisant sens pour
les utilisateurs qui veulent aller à la pêche à pied ou bronzer sur le
sable à marée basse!




Le 10 février 2016 à 23:22,   a écrit :
> Ça ne vaut pas encore le coin de l'Aber dans la presqu'ile de Crozon (*)
> pour la précision (par contre pour créer la relation soit il maîtrise QGis
> ou autre soit il a galéré).
> http://www.openstreetmap.org/#map=15/48.2309/-4.4390
> http://tile.openstreetmap.fr/?zoom=15=48.23094=-4.43548=B000FF
>
> En théorie pour les plages un outil devrait permettre de la tracer et de la
> nommer bêtement et découper de part et d'autre de la ligne de côte (avec un
> tidal=yes en aval) et le nom porté par la relation qui compose les deux.
> Ou plutôt sur un nœud ayant le rôle label: pas besoin de nouveau tag.
> Bien sûr je parle d'endroit où la ligne de côte est une vraie ligne de côte.
>
> Pour les lignes artificielles (embouchures) ça me dérange d'ailleurs d'avoir
> un natural=coastline.
> Je proposerais bien un natural=virtual_coastline ou d'ajouter un
> virtual=yes.
> Si et seulement si on ne souhaite pas remonter dans les estuaires le long du
> coef de 95.
>
> Or le wiki précise :
> quand la législation locale définit un domaine maritime (par exemple en
> France les lois protégeant le littoral), on fera remonter les lignes de
> côtes assez haut dans le fleuve pour qu'elles bordent entièrement ce domaine
> maritime, même s'il y a un ouvrage d'art traversant l'estuaire plus bas en
> aval.
>
> Donc on a maintenant du boulot (et la Laïta qui est la partie maritime de
> l'Ellé cesse d'être une riverbank ? et devient natural=water, tidal=yes ?)
>
> Des objections ?
>
> Jean-Yvon
> (*) vous avez vu, l'ile a perdu son accent circonflexe, pour le nom de
> l'Île-de-Sein il faut un décret ou on doit mettre name=Ile-de-Sein et
> old_name=Île-de-Sein ?). Autre solution sur tout fr:name remplacer à
> l'affichage les Î par des I.
>
>
>
> Le 10/02/2016 22:43, Eric Debeau - eric.deb...@gmail.com a écrit :
>
> Bonsoir
>
> C'est justement l'extraction des données de OSM et le contour de
> Lannion-Tregor Communaté pour réaliser ce support que j'ai vu des données
> qui m'ont interpellé.
>
> Sur le GR34 qui passe sur une zone en dehors de la terre ferme, je ne suis
> pas surpris. J'irai vérifier sur le terrain, mais je pense que c'est
> probable à cause justement des constructions et malheureusement le respect
> de la servitude de passage des piétons le long du littoral n'est pas
> toujours respecté, mais en Bretagne, on n'a pas trop à se plaindre par
> rapport à d'autres régions.
> Je trouve que ce serait intéressant de montrer les zones de servitudes de
> passage du littoral sur OSM.
>
> C'est vrai qu'il manque beaucoup d'information sur l'estran sur OSM. J'ai vu
> une avancée intéressante du coté de Penvenan:
> http://www.openstreetmap.org/relation/5449871
>
> Avec les informations des Orthophotos de Geolittoral, on doit pouvoir
> indiquer les zones découvertes. Après, il y a du boulot pour distinguer les
> rochers, de la vase, du sable, des galets...
>
> J'ai regardé sur la France, il y a seulement 192 objets avec tidal=yes
>
> Sur les plages, je pense qu'il manque un tag représentant l'ensemble de la
> plage au dessus en en dessous de la ligne de cote. Le nom d'une plage ne
> fait pas de différence entre ces 2 parties et pour l'instant il faut ajouter
> le champ name dans les 2 parties.
>
> Eric
>
> 2016-02-10 1:31 GMT+01:00 :
>>
>> Tu veux dire le chemin E9 dont certains ont déposé pour la partie
>> française GR 34 ? ;-).
>> Elles sont effectivement là en dehors de la terre ferme, c'est un fait.
>> Le problème ici n'est pas tant tidal=sand ou beach mais l'absence de tag
>> qui fait penser à la pleine mer.
>> Très clairement là, le chemin passe sur un endroit recouvert d'eau à marée
>> haute ordinaire.
>>
>> Enfin le vrai problème c'est que l'on ne fait pas respecter la servitude
>> littorale mais c'est un autre sujet.
>>
>> N. B. : concrètement, est-ce que tu penses :
>>
>> http://mc.bbbike.org/mc/?lon=-3.505597=48.825301=18=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=limite%20de%20la%20plage%20?
>> Ça ne me choque pas mais la différence c'est plus natural=sand au dessus
>> (d'un point de vue altimétrique, au sud ici) et au nord c'est plutôt de la
>> vase.
>> Ne mettre que beach dans la partie de coef supérieur à 100 va minimiser
>> les plages, certes.
>> Mais que le piéton sache qu'il peut être coincé par la marée me semble
>> plutôt une précision utile. Pas sûr que le trait de côte suffise.
>> Mettrais-tu un tidal=yes ?
>>
>> Alors près du lieu de vacances d'Antoine (pour ceux qui ont suivi) :
>>
>>

Re: [OSM-talk-fr] eaux intérieures (était Image of the week)

2016-02-10 Par sujet Christian Rogel 
Le 10 févr. 2016 à 23:22, osm.sanspourr...@spamgourmet.com a écrit 
> (*) vous avez vu, l'ile a perdu son accent circonflexe, pour le nom de 
> l'Île-de-Sein il faut un décret ou on doit mettre name=Ile-de-Sein et 
> old_name=Île-de-Sein ?). Autre solution sur tout fr:name remplacer à 
> l'affichage les Î par des I.

Je suppose que c'est de l'humour : Le décret n'impose à personne de changer la 
moindre façon d'écrire. Les nouveautés ne seront plus sanctionnables lors des 
examens officiels.
Quant à l'INSEE, elle continuera comme avant sans rien changer aux noms de 
lieu, dont elle a la garde.

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

Re: [OSM-talk-fr] Doute sur le calage Bing/Cadastre

2016-02-10 Par sujet Tyndare 
Dans le menu contextuel du calque Strava (clique droit), il y a la
case à cocher «Zoomer automatiquement» qu'il faut désactiver une fois
qu'on est au zoom maximum disponible.

Le 10 février 2016 à 17:10, JB  a écrit :
> Le 09/02/2016 12:01, Tyndare a écrit :
> J'apprécie aussi Strava dans les zones où les VTTistes passent, et regrette
> la faible visibilité et manque de zoom aux échelles de traçage.
> Mais désactiver le zoom automatique, tu fais ça comment ?
> JB.

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

Re: [OSM-talk-fr] Image of the week

2016-02-10 Par sujet Philippe Verdy 
Le 10 février 2016 à 22:43, Eric Debeau  a écrit :

>
> Sur les plages, je pense qu'il manque un tag représentant l'ensemble de la
> plage au dessus en en dessous de la ligne de cote. Le nom d'une plage ne
> fait pas de différence entre ces 2 parties et pour l'instant il faut
> ajouter le champ name dans les 2 parties.
>

Ce tag ne manque pas. Les deux parties sont à réunir dans "natural=beach",
avec son nom. Solution simple. Sur le rendu de base OSM on ne verra que la
partie haute en jaune puisque le bas sera "sous l'eau" dans la zone bleue.
Mais une rendu pourrait malgré tout afficher cette partie basse de la plage
en semi-transparence, donnant un turquoise ou un bleu plus clair...

La ligne de côte d'OSM (natural=coastline) passera au milieu
(hauteur/coefficient à décider) mais ce n'est pas du tout gênant. La zone
"tidal" entourera cette ligne de côte des deux côtés, et parfois englobera
la totalité de la plage (elle englobera aussi des rochers et des vasières
(natural=*) attenant à la plage (natural)=beach), mais il ne devrait y
avoir aucun morceau de la plage plus bas que la zone tidal (après c'est
juste un fond sableux du plateau continental toujours sous l'eau, mais dans
cette partie il y a une faune et une flore spécifique et souvent le roc ou
les cailloux affleurent un peu partout).

La ligne de base passera le plus souvent bien au delà, dans l'eau, et
servira pour délimiter les frontières de communes/départements/régions...
(pas besoin de nouveau tag, ou alors "boundary=baseline" et "maritime=yes",
pas d'admin_level mais si une valeur est donnée c'est "admin_level=4"
puisque ce n'est pas la frontière de la France elle-même ni de la France
métropolitaine, juste une limite pour les collectivités territoriales, EPCI
et autres groupements adminsitratifs)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] eaux intérieures (était Image of the week)

2016-02-10 Par sujet Philippe Verdy 
Le 10 février 2016 à 23:22,  a écrit :

> Ça ne vaut pas encore le coin de l'Aber dans la presqu'ile de Crozon (*)
> pour la précision (par contre pour créer la relation soit il maîtrise QGis
> ou autre soit il a galéré).
> (*) vous avez vu, l'ile a perdu son accent circonflexe, pour le nom de
> l'Île-de-Sein il faut un décret ou on doit mettre name=Ile-de-Sein et
> old_name=Île-de-Sein ?). Autre solution sur tout fr:name remplacer à
> l'affichage les Î par des I.
>

Que je sache, l'intervention récente du gouvernement n'a rien changé, c'est
la même réforme orthographique de 1990 qui est rappelée (dont le texte
complet est depuis plusieurs années dans Wikisource dans sa forme originale
telle que publiée au JORF), et autorise pour l'orthographe courante, la
suppression des accents circonflexes non significatifs, mais ne les abolit
pas: ils sont toujours corrects. La réforme de 1990 ne touche pas non plus
les noms propres (les toponymes) qui n'ont pas à changer.


Ce que le gouvernement a voulu rappeler aux enseignants était qu'ils
avaient le choix de l'orthographe mais qu'il ne devaient pas sanctionner
une faute sur l'orthographe de 1990.
Si c'est plus facile pour les enseignants d'aborder l'orthographe en
utilisant celle de 1990, ils peuvent le faire. Mais pas empêcher non plus
les élèves de découvrir et utiliser eux-mêmes les formes traditionnelles.
Ils n'ont pas besoin non plus de passer du temps à expliquer les deux
orthographes, à moins qu'on le leur demande explicitement, il y a d'autres
choses plus importantes à enseigner. Mais bien des enseignants ont mal
compris cette réforme en croyant qu'elle avait un impact impératif alors
qu'elle est sensée être une aide et non une difficulté de plus.

En revanche il y a des accents essentiels à conserver et enseigner,
notamment les accents aigus sur les participes, souvent confondus avec les
infinitifs, ou les marques correctes du pluriel.

Si ça le dit à quelqu'un il peut toujours ajouter un "alt_name=*" sans
l'accent circonflexe, mais je ne l'ôterai pas de la forme normale name=*.
Les lecteurs ne seront pas choqués de voir ces accents et les omettront
d'eux-mêmes, volontairement ou pas, mais ils hésiteront à en mettre en
croyant faire une faute parce que cette orthographe traditionnelle ne le
sera plus exposée la plupart du temps. Je ne pense malgré tout même pas
qu'il soit nécessaire de mettre les alt_name, même pour les recherches de
lieux (qui savent déjà interprêter des mots non accentués pour trouver les
mots accentués).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] eaux intérieures (était Image of the week)

2016-02-10 Par sujet Philippe Verdy 
Le 10 février 2016 à 23:22,  a écrit :

> Ça ne vaut pas encore le coin de l'Aber dans la presqu'ile de Crozon (*)
> pour la précision (par contre pour créer la relation soit il maîtrise QGis
> ou autre soit il a galéré).
> (*) vous avez vu, l'ile a perdu son accent circonflexe, pour le nom de
> l'Île-de-Sein il faut un décret ou on doit mettre name=Ile-de-Sein et
> old_name=Île-de-Sein ?). Autre solution sur tout fr:name remplacer à
> l'affichage les Î par des I.
>

Que je sache, l'intervention récente du gouvernement n'a rien changé, c'est
la même réforme orthographique de 1990 qui est rappelée (dont le texte
complet est depuis plusieurs années dans Wikisource dans sa forme originale
telle que publiée au JORF), et autorise pour l'orthographe courante, la
suppression des accents circonflexes non significatifs, mais ne les abolit
pas: ils sont toujours corrects. La réforme de 1990 ne touche pas non plus
les noms propres (les toponymes) qui n'ont pas à changer.

L'Île-de-Sein conserve donc son accent tant que la commune ne passe pas une
décision officielle de changement de nom (L'Insee se mettra à jour). De
même les traits d'union sont conservés dans les noms de communes qui les
ont (on voit dans les communes nouvelles une tendance à les abolir en
partie dans leur nouveau nom à rallonge, mais c'était déjà le cas pour
d'autres collectivités comme les Pays de la Loire ou le Territoire de
Belfort ou plus récemment avec le Centre-Val de Loire). Il y a eu un temps
où c'était une norme en principe obligatoire en France (et dans les
anciennes colonies, qui depuis leur indépendances les ont abolis...)

Ce que le gouvernement a voulu rappeler aux enseignants était qu'ils
avaient le choix de l'orthographe mais qu'il ne devaient pas sanctionner
une faute sur l'orthographe de 1990.
Si c'est plus facile pour les enseignants d'aborder l'orthographe en
utilisant celle de 1990, ils peuvent le faire. Mais pas empêcher non plus
les élèves de découvrir et utiliser eux-mêmes les formes traditionnelles.
Ils n'ont pas besoin non plus de passer du temps à expliquer les deux
orthographes, à moins qu'on le leur demande explicitement, il y a d'autres
choses plus importantes à enseigner. Mais bien des enseignants ont mal
compris cette réforme en croyant qu'elle avait un impact impératif alors
qu'elle est sensée être une aide et non une difficulté de plus.

En revanche il y a des accents essentiels à conserver et enseigner,
notamment les accents aigus sur les participes, souvent confondus avec les
infinitifs, ou les marques correctes du pluriel.

Si ça le dit à quelqu'un il peut toujours ajouter un "alt_name=*" sans
l'accent circonflexe, mais je ne l'ôterai pas de la forme normale name=*.
Les lecteurs ne seront pas choqués de voir ces accents et les omettront
d'eux-mêmes, volontairement ou pas, mais ils hésiteront à en mettre en
croyant faire une faute parce que cette orthographe traditionnelle ne le
sera plus exposée la plupart du temps. Je ne pense malgré tout même pas
qu'il soit nécessaire de mettre les alt_name, même pour les recherches de
lieux (qui savent déjà interprêter des mots non accentués pour trouver les
mots accentués).

Le 11 février 2016 à 03:20, Jérôme Amagat  a écrit
:

> Les changements date d'il y a 25 ans  et rien n'est imposé.
> Sinon je pense que c'est faut décrire Ile-de-Sein c'est un nom propre qui
> ne doit avoir qu'une orthographe.
>
> Le mercredi 10 février 2016, Christian Rogel <
> christian.ro...@club-internet.fr> a écrit :
>
>> Le 10 févr. 2016 à 23:22, osm.sanspourr...@spamgourmet.com a écrit
>> > (*) vous avez vu, l'ile a perdu son accent circonflexe, pour le nom de
>> l'Île-de-Sein il faut un décret ou on doit mettre name= et
>> old_name=Île-de-Sein ?). Autre solution sur tout fr:name remplacer à
>> l'affichage les Î par des I.
>>
>> Je suppose que c'est de l'humour : Le décret n'impose à personne de
>> changer la moindre façon d'écrire. Les nouveautés ne seront plus
>> sanctionnables lors des examens officiels.
>> Quant à l'INSEE, elle continuera comme avant sans rien changer aux noms
>> de lieu, dont elle a la garde.
>>
>> C.
>> ___
>> 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] Erosion du littoral : une cartographie des côtes françaises est disponible

2016-02-10 Par sujet Philippe Verdy 
Le 11 février 2016 à 05:36, Jérôme Amagat  a écrit
:

> wetland=tidalflat
> Tidalflat~ milieu intertidal ou alors ça se rapproche de mudflat comme le
> dit le wiki
> Mudflat= vasière
>
> (Moi j'aurai tendance a dire que la limite plage vasière c'est pas la
> coastline et que la plage descend plus bas. Et c'est compliqué d'avoir un
> vrai limite.
> Ce n'est pas dit que ce qui est écrit sur la page du wiki est été discuté
> et soit donc le meilleur choix)
>

Pour moi une vasière n'est plus une plage, même si elle est découverte à
marée basse (dans ce cas la zone "tidal" inclut à la fois le bas
submersible de la plage et la partie haute découvrable de la vasière. (Il
peut arriver que la plage et la vasière n'aient pas de nom distinctif dans
l'usage local, mais on ses contentera juste de nommer la plage et on
laissera la vasière anonyme).

"tidalflat" pour moi ne sert strictement à rien, il est trop ambigu:
préciser plutôt "beach" (+ précision si c'est du sable ou des galets) ou
"mudflat" ou "rock" ou "mangrove" ou "coral_reef", etc. pour préciser le
type de sol, et délimiter ensuite plutôt la zone "tidal" toute entière pour
en inclure tout ou partie.

Ce n'est pas du tout compliqué à taguer, c'est ce qui est le mieux visible
sur le terrain et sur les photos (à condition d'avoir des photos à marée
basse). Ce qui est plus difficile à voir c'est le bas de la vasière, assez
approximatif, mais on est déjà là sous l'eau en permanence (mais peut-être
qu'on a des données du SHOM qui précise les types de sols sur le plateau
continental pour affiner ce tracé sous-marin et ça peut servir aux marins
pour l'accostage voire le mouillage s'il est autorisé, pour savoir où jeter
l'ancre sans labourer des zones protégées). Ces vasières sont souvent aussi
des zones privilégiées pour les parcs d'huitres ou de moules (faciles à
repérer et cartographier, on les voit très bien sur les photos même quand
ils sont submergées en permanence à faible profondeur).

Vasières et plages (aussi les mangroves) sont des milieux naturels
différents par la nature même du sol et ses espèces. Plages et vasières
cartographient le milieu naturel tel qu'il est, sans aucune référence aux
frontières administratives, ni même au fait qu'une partie est soumise ou
pas à la marée (zone "tidal"). Même remarque d'ailleurs pour les estuaires,
qu'on sépare de la mer uniquement par un trait relativement arbitraire soit
par nature des eaux, soit par la présence d'un barrage.. mais qui ont aussi
des plages soumises aussi à la marée, une ligne de côte, des vasières, des
zones rocheuses...

D'ailleurs les plages concernent aussi le milieu non maritime (autour des
lacs et étangs, qu'ils soient artificiels et créés par un barrage, ou
naturels et juste traversés par un petit cours d'eau avec des passes à
débordement sur un haut-fond rocheux, ou alimentés/purgés par de simples
fossés ou canaux ou par des infractuosités/siphons naturels dans le sol).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Erosion du littoral : une cartographie des côtes françaises est disponible

2016-02-10 Par sujet Jérôme Amagat 
(J'y connais rien en marée et en mer)

Si on résume :

Limite terre mer :
En France :
trait de côte : laisse des plus hautes mers dans le cas d’une marée
astronomique de coefficient 120 et dans des conditions météorologiques
normales.
(On a des donnée libre)

Osm :
natural=coastline
D'après le wiki: C'est la Mean high water spring qui est la laisse des plus
hautes mers pour une marée haute de coefficient 95.

Plage :
D'après osm, la limite basse c'est natural=coastline
Tag pouvant être utiliser en dessous :
Tidal=yes mais je dirais qu'on peut l'avoir aussi au dessus jusqu'au trait
de cote français, la marée de coef 120

wetland=tidalflat
Tidalflat~ milieu intertidal ou alors ça se rapproche de mudflat comme le
dit le wiki
Mudflat= vasière

(Moi j'aurai tendance a dire que la limite plage vasière c'est pas la
coastline et que la plage descend plus bas. Et c'est compliqué d'avoir un
vrai limite.
Ce n'est pas dit que ce qui est écrit sur la page du wiki est été discuté
et soit donc le meilleur choix)

Ligne de base:
Formé à partir de la laisse de basse mer et de ligne de base droite.
Ce que j'ai compris c'est que cette ligne en elle même ne sert à rien, elle
sert seulement à tracer d'autres lignes qui elles ont une utilité (limite
de la mer territoriale entre autres)

Eaux intérieurs : nom donné aux eaux entre la terre et la ligne de base.
Ne sert à rien (?)

domaine public maritime :
http://www.developpement-durable.gouv.fr/Consistance-du-domaine-public.html
Il s'étend du trait de côte jusqu'à la limite des eaux territoriales et
comprend aussi des lais et relais de la mer. (Pour les dom Tom c'est un peu
différent: il empiète de 50 pas sur la terre).
Il est géré par l'état (préfet maritime) et pas par commune, département et
région.
L'état peut concéder une partie de ce domaine pour qu'il soit exploité (
des plages par des communes par exemple).

(Je diras que si c'est dans le DPM c'est pas dans la commune donc on a la
limite des communes littorales?)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Académies...

2016-02-10 Par sujet Philippe Verdy 
"border_type=educational" est déjà décrit et tout à fait approprié.

"academy" est un faux-ami en anglais (c'est un type d'école spécialisée à
caractère professionnel ou culturel, hors du cadre éducatif général) qui
n'a rien à voir avec nos académies administratives; il est aussi utilisé en
anglais, avec la majuscule, pour les institutions linguistiques nationales
ou régionales (sur le modèle de notre Académie française).

S'il faut des découpages ou regroupements, ce sera "educational_level"=*

(ne surtout pas refaire "admin_level=*" comme cela a été fait abusivement
pour les frontières religieuses, qui sont des frontières privées qui n'ont
rien d'administratif, et qui auraient du utiliser "religious_level=*" en
plus de boundary="religious" et "denomination=catholic", voire même plus
spécifiquement "catholic_level=*" puisque ce sont uniquement des divisions
catholiques). La réutilisation de tags pour des usages complètement
orthogonaux est plus un problème qu'une facilité et n'apporte rien en terme
de cohérence ou de volume dans la base de données. Ajouter un nouveau tag
ne demande qu'une page dans le wiki (ou corriger la page existante déjà
consacrée à ce type de frontière).

Le 10 février 2016 à 11:33, Jérôme Seigneuret  a
écrit :

> Bonjour,
> tu peux aussi ajouter border_type=academy
>
> academy_level=*
> A définir s'il y a des sous découpages
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Académies...

2016-02-10 Par sujet Philippe Verdy 
Le 10 février 2016 à 12:54, David Crochet  a écrit :

> Bonjour
>
> Le 10/02/2016 11:33, Jérôme Seigneuret a écrit :
>
>>
>> academy_level=*
>> A définir s'il y a des sous découpages
>>
>
> 1 : ministère
> 2 : académie régional
> 3 : académie
> 4 : départemental
> 5 : circonscription
> 6 : carte scolaire
>
> Pour clarifier, j'aurais plutôt calqué les niveaux sur les niveaux
administratifs à peu près équivalents:

2 = ministère (est-ce utile? duplique la relation France)
3 = académies d'outre-mer (ou regroupement des académies de métropole,
est-ce utile? duplique les relations administratives des régions
d'outre-mer), ce pourrait être les zones A/B/C en métropole
4 = grande académie régionale (en métropole uniquement)
5 = académie interdépartementale (en métropole uniquement)
6 = départementale (en métropole uniquement)
7 = circonscription (compétence des EPCI... il est possible que cela
fusionne totalement à terme avec les contours des EPCI dans plein
d'endroits, surtout en milieu rural)
8 = carte scolaire (municipal, voire intercommunal mais plus petit qu'un
EPCI)
9 = carte scolaire locale (niveau quartiers ou groupes de quartiers ou
arrondissement municipal, dans les grandes villes)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

2016-02-10 Par sujet Ab_fab 
Pour compléter la réponse à Jean-Michel,

Concernant les services NTRIP maison, Lance Lefebure (un agriculteur
américain) a bossé il y a quelque temps sur le sujet et met le fruit de ses
travaux à disposition (y compris le code)
http://lefebure.com/software/

Ainsi que quelques articles, entre autres
http://lefebure.com/articles/



Le 9 février 2016 à 23:08, Stéphane Péneau  a
écrit :

> Le 09/02/2016 20:17, Jean-Michel Pouré a écrit :
>
>> OK, je comprends. Je suis à 30 km de la station de Creil. C'est suffisant
>> pour avoir une certaine précision, sans descendre à 2cm ?
>>
>
> Je ne peux pas te répondre, il faut essayer. Ce sera forcément beaucoup
> plus problématique en zone urbaine, à cause de l'effet "canyon" (les
> immeubles qui bloquent une partie des satellites et génèrent des rebonds).
>
> Le 09/02/2016 21:30, Jean-Michel Pouré a écrit :
>
>> Je dispose de quelques machines embarquées et de serveurs récents. Quel
>> matériel me faut-il pour démarrer une station NTRIP ? La fonction
>> émission radio ne m'intéresse pas. Quelle puce de suivi satellite me
>> conseillez-vous ?
>>
>> J'ai lu dans la documentation EUREF qu'il fallait un accès à la
>> totalité du ciel et qu'on devait utiliser un matériel à auto-calibrage.
>> RTKlib peut-il faire l'affaire ?
>>
> Je ne connais que très peu les spécifications minimum pour une station
> Ntrip "officielle", mais il me semble que la précision de l'horloge est
> primordiale, ainsi que la qualité de l'antenne de réception et sa
> calibration.
> Tous ces paramètres sont un peu moins cruciaux lorsqu'on se crée sa propre
> station de base personnelle.
>
> En récepteur, je ne m'y connais pas énormément. Je sais que les u-blox.com
> sont assez régulièrement utilisés pour le diy. Perso je suis chez Navspark.
> Pour en faire des stations de base, il faut qu'ils fournissent les données
> RAW.
> Il doit exister des softs open source pour la conversion RAW->RTCM->NTRIP
> mais je ne me suis pas trop penché sur le sujet pour le moment. En
> revanche, notre cher Ratzilla$ bosse sur le sujet, il en parle un peu sur
> son twitter :
> https://twitter.com/RatZillaS
>
>
> La matériel à mettre en oeuvre n'a pas l'air phénoménal et j'ai
>> l'impression qu'une installation comprenant matériel embarqué, câble
>> réseau, puce de réception ne doit pas coûter très cher en DIY. A la
>> limite, on peut imaginer un matériel PoE à placer sur le toit.
>>
>> Qu'est-ce que vous en pensez ? N'est-ce pas le type de projet qu'une
>> communauté devrait gérer ?
>>
> Oui, ce serait très intéressant. Et il existe déjà des communautés qui le
> font : les agriculteurs, particulièrement ceux qui cultivent de grandes
> surfaces, comme les céréaliers. Mais leurs réseaux de stations ne sont en
> général pas ouverts.
>
> Pour un accès libre à tous, il y a un début de projet :
> http://pylongps.com/doku.php
>
> En tout cas, si tu avances sur le sujet, n'hésite pas à partager.
>
>
> Stf
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Académies...

2016-02-10 Par sujet Jérôme Seigneuret 
Bonjour,
tu peux aussi ajouter border_type=academy

academy_level=*
A définir s'il y a des sous découpages

Sinon c'est plutôt clair.


PS: Si ça peut aussi être servir et être coupler avec le tag *opening_hours*
pour utiliser le zonage A, B, C et la valeur *SH*

*SH:Zone_A* par exemple... qui n'est pas stipuler sur le wiki non plus.
C'est une réflexion qui permettrait d'avoir des infos plus clair sur la
période d' ouverture de service en période de vacance scolaire. Je dis ça
car en zone limite, ce ne sera pas forcément l'emprise englobante du
périmètre qui définira la tranche d'ouverture.

Jérôme



Le 9 février 2016 à 18:52, Christian Quest  a
écrit :

> J'ai rajouté les limites des académies et les nouvelles zones pour les
> vacances scolaires...
>
> Je n'ai rien trouvé d'existant en terme de tags, à part 2
> boundary=educational
>
> Cela donne:
> type=boundary
> boundary=educational
> boundary_type:FR=Circonscription académique
> holiday_zone=A/B/C
> name=Académie de XXX
>
> Si vous avez mieux à proposer n'hésitez pas.
>
> J'ai aussi mis à jour la pauvre relation type=defaults de la Zone A et
> créé celles des zones B et C.
>
> Il existe depuis le 1/1/2016 la notion de "Région académique", qui sont
> les regroupements des circonscriptions académiques de chacune des
> nouvelles régions.
>
> Accès overpass: http://overpass-turbo.eu/s/ejb
>
> Et un export en shapefile est disponible:
>
> http://osm13.openstreetmap.fr/~cquest/openfla/export/academies-20160209-shp.zip
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Académies...

2016-02-10 Par sujet Christian Quest 
On 10/02/2016 11:33, Jérôme Seigneuret wrote:
> Bonjour, 
> tu peux aussi ajouter border_type=academy
>
> academy_level=*
> A définir s'il y a des sous découpages
>
> Sinon c'est plutôt clair.
>

Je n'ai pas trouvé de tags existants de ce type, j'évite d'en créer...
c'est trop facile ;)

Pour le sous découpage, en fait il y a un sur-découpage avec les
"Régions académiques" qui sont un nouveau regroupement créé au 1/1/2016
mais qui en fait reprend le nouveau découpage des régions. Ce n'est donc
pas très utile avoir un doublon à ce niveau.


>
> PS: Si ça peut aussi être servir et être coupler avec le tag
> *opening_hours* pour utiliser le zonage A, B, C et la valeur *SH*
>
> /*SH:Zone_A*/ par exemple... qui n'est pas stipuler sur le wiki non
> plus. C'est une réflexion qui permettrait d'avoir des infos plus clair
> sur la période d' ouverture de service en période de vacance scolaire.
> Je dis ça car en zone limite, ce ne sera pas forcément l'emprise
> englobante du périmètre qui définira la tranche d'ouverture.
>

Euh... pas compris.


Depuis hier, j'ai ajouté les tags wikipedia=*


> Jérôme
>
>
>
> Le 9 février 2016 à 18:52, Christian Quest  > a écrit :
>
> J'ai rajouté les limites des académies et les nouvelles zones pour les
> vacances scolaires...
>
> Je n'ai rien trouvé d'existant en terme de tags, à part 2
> boundary=educational
>
> Cela donne:
> type=boundary
> boundary=educational
> boundary_type:FR=Circonscription académique
> holiday_zone=A/B/C
> name=Académie de XXX
>
> Si vous avez mieux à proposer n'hésitez pas.
>
> J'ai aussi mis à jour la pauvre relation type=defaults de la Zone A et
> créé celles des zones B et C.
>
> Il existe depuis le 1/1/2016 la notion de "Région académique", qui
> sont
> les regroupements des circonscriptions académiques de chacune des
> nouvelles régions.
>
> Accès overpass: http://overpass-turbo.eu/s/ejb
>
> Et un export en shapefile est disponible:
> 
> http://osm13.openstreetmap.fr/~cquest/openfla/export/academies-20160209-shp.zip
> 
> 
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

2016-02-10 Par sujet Stéphane Péneau 
A priori il faut faire attention avec le Lefebure NTRIP Caster qui 
aurait une fuite mémoire. J'ai dû lire ça sur la liste FOSS-GPS il me 
semble.


Au passage, je viens de découvrir un nouveau venu dans le monde des 
modules tout prêt, et il est français :

http://www.drotek.com/shop/fr/home/762-gnss-rtk-l1.html
Fonctionne sur 1 seul fréquence, GPS+GLONASS+GALILEO. 10hz max. C'est 
très orienté drone, et assez proche de ce que propose emlid avec le 
"Reach" : récepteur U-Blox Neo M8T + carte Intel edison pour faire 
tourner la librairie RTKLIB.


Stf



Le 10/02/2016 10:51, Ab_fab a écrit :

Pour compléter la réponse à Jean-Michel,

Concernant les services NTRIP maison, Lance Lefebure (un agriculteur 
américain) a bossé il y a quelque temps sur le sujet et met le fruit 
de ses travaux à disposition (y compris le code)

http://lefebure.com/software/

Ainsi que quelques articles, entre autres
http://lefebure.com/articles/



Le 9 février 2016 à 23:08, Stéphane Péneau > a écrit :


Le 09/02/2016 20:17, Jean-Michel Pouré a écrit :

OK, je comprends. Je suis à 30 km de la station de Creil.
C'est suffisant pour avoir une certaine précision, sans
descendre à 2cm ?


Je ne peux pas te répondre, il faut essayer. Ce sera forcément
beaucoup plus problématique en zone urbaine, à cause de l'effet
"canyon" (les immeubles qui bloquent une partie des satellites et
génèrent des rebonds).

Le 09/02/2016 21:30, Jean-Michel Pouré a écrit :

Je dispose de quelques machines embarquées et de serveurs
récents. Quel
matériel me faut-il pour démarrer une station NTRIP ? La fonction
émission radio ne m'intéresse pas. Quelle puce de suivi
satellite me
conseillez-vous ?

J'ai lu dans la documentation EUREF qu'il fallait un accès à la
totalité du ciel et qu'on devait utiliser un matériel à
auto-calibrage.
RTKlib peut-il faire l'affaire ?

Je ne connais que très peu les spécifications minimum pour une
station Ntrip "officielle", mais il me semble que la précision de
l'horloge est primordiale, ainsi que la qualité de l'antenne de
réception et sa calibration.
Tous ces paramètres sont un peu moins cruciaux lorsqu'on se crée
sa propre station de base personnelle.

En récepteur, je ne m'y connais pas énormément. Je sais que les
u-blox.com  sont assez régulièrement utilisés
pour le diy. Perso je suis chez Navspark. Pour en faire des
stations de base, il faut qu'ils fournissent les données RAW.
Il doit exister des softs open source pour la conversion
RAW->RTCM->NTRIP mais je ne me suis pas trop penché sur le sujet
pour le moment. En revanche, notre cher Ratzilla$ bosse sur le
sujet, il en parle un peu sur son twitter :
https://twitter.com/RatZillaS


La matériel à mettre en oeuvre n'a pas l'air phénoménal et j'ai
l'impression qu'une installation comprenant matériel embarqué,
câble
réseau, puce de réception ne doit pas coûter très cher en DIY.
A la
limite, on peut imaginer un matériel PoE à placer sur le toit.

Qu'est-ce que vous en pensez ? N'est-ce pas le type de projet
qu'une
communauté devrait gérer ?

Oui, ce serait très intéressant. Et il existe déjà des communautés
qui le font : les agriculteurs, particulièrement ceux qui
cultivent de grandes surfaces, comme les céréaliers. Mais leurs
réseaux de stations ne sont en général pas ouverts.

Pour un accès libre à tous, il y a un début de projet :
http://pylongps.com/doku.php

En tout cas, si tu avances sur le sujet, n'hésite pas à partager.


Stf

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




--
ab_fab 
"Il n'y a pas de pas perdus", Nadja


___
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] Académies...

2016-02-10 Par sujet Jérôme Seigneuret 
*SH* c'est la valeur qui permet d'ajouter,de gérer, les horaires
d'ouvertures et de fermetures en périodes de vacances scolaires.

Ces vacances sont liées aux zones que tu as mentionnées mais ces zones ne
sont pas identifiables quand tu renseignes *opening_hours*.
Si les horaires sont connus par zones, on peut le renseigner ou exploiter
les entités correspondant à *"boundary_type:FR=Circonscription
académique" + "holiday_zone=A|B|C*

*holiday_zone=** pourrait permettre de spécifier les jours d'ouvertures
pour les autres éléments (shop, office... utilisant un *opening_hours=SH
off*.

*SH* ne spécifie actuellement pas la zone en question. Cette clé ne fournie
pas d'information précise quand la période des jours de vacances scolaires
de chaque zone est différente.

On peut surement renseigner et exploiter les horaires scolaires des zones à
quelque part et via un schéma de tag.
La relation entre les horaires de vacances scolaires par zone pourrait à
terme être exploité par
*opening_hours=SH: on|off*

Coté *holiday_zone* je serais même pour mettre : le schéma *holiday_zone=<**ISO
3166-1>: *car ces zones sont spécifique à notre pays et c'est pas sur
qu'une zone A n'existe pas dans un autre pays
*holiday_zone=FR:A|B|C*

Voilà l'idée.


Le 10 février 2016 à 12:13, Christian Quest  a
écrit :

> On 10/02/2016 11:33, Jérôme Seigneuret wrote:
>
> Bonjour,
> tu peux aussi ajouter border_type=academy
>
> academy_level=*
> A définir s'il y a des sous découpages
>
> Sinon c'est plutôt clair.
>
>
> Je n'ai pas trouvé de tags existants de ce type, j'évite d'en créer...
> c'est trop facile ;)
>
> Pour le sous découpage, en fait il y a un sur-découpage avec les "Régions
> académiques" qui sont un nouveau regroupement créé au 1/1/2016 mais qui en
> fait reprend le nouveau découpage des régions. Ce n'est donc pas très utile
> avoir un doublon à ce niveau.
>
>
>
> PS: Si ça peut aussi être servir et être coupler avec le tag
> *opening_hours* pour utiliser le zonage A, B, C et la valeur *SH*
>
> *SH:Zone_A* par exemple... qui n'est pas stipuler sur le wiki non plus.
> C'est une réflexion qui permettrait d'avoir des infos plus clair sur la
> période d' ouverture de service en période de vacance scolaire. Je dis ça
> car en zone limite, ce ne sera pas forcément l'emprise englobante du
> périmètre qui définira la tranche d'ouverture.
>
>
> Euh... pas compris.
>
>
> Depuis hier, j'ai ajouté les tags wikipedia=*
>
>
>
> Jérôme
>
>
>
> Le 9 février 2016 à 18:52, Christian Quest  a
> écrit :
>
>> J'ai rajouté les limites des académies et les nouvelles zones pour les
>> vacances scolaires...
>>
>> Je n'ai rien trouvé d'existant en terme de tags, à part 2
>> boundary=educational
>>
>> Cela donne:
>> type=boundary
>> boundary=educational
>> boundary_type:FR=Circonscription académique
>> holiday_zone=A/B/C
>> name=Académie de XXX
>>
>> Si vous avez mieux à proposer n'hésitez pas.
>>
>> J'ai aussi mis à jour la pauvre relation type=defaults de la Zone A et
>> créé celles des zones B et C.
>>
>> Il existe depuis le 1/1/2016 la notion de "Région académique", qui sont
>> les regroupements des circonscriptions académiques de chacune des
>> nouvelles régions.
>>
>> Accès overpass: http://overpass-turbo.eu/s/ejb
>>
>> Et un export en shapefile est disponible:
>>
>> http://osm13.openstreetmap.fr/~cquest/openfla/export/academies-20160209-shp.zip
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Académies...

2016-02-10 Par sujet David Crochet 

Bonjour

Le 10/02/2016 11:33, Jérôme Seigneuret a écrit :


academy_level=*
A définir s'il y a des sous découpages


1 : ministère
2 : académie régional
3 : académie
4 : départemental
5 : circonscription
6 : carte scolaire

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] amenity=townhall et place=village à séparer ?

2016-02-10 Par sujet osm . sanspourriel 

Le 10/02/2016 22:24, Nicolas Moyroud - nmoyr...@free.fr a écrit :
D'ailleurs les nœud place=village ne devrai je pense n'être accrocher 
a rien. 

En théorie oui, en pratique à vérifier.
J'ai vu des moteurs de routage ne pas savoir aller à un endroit parce 
qu'il était à 5 m de la route sans chemin piéton pour y aller.


Le 10/02/2016 22:27, Christian Quest - cqu...@openstreetmap.fr a écrit :
Ces noeuds place=* servent plus ou moins de role de label pour les 
relations définissant les limites des communes.


En fait tout ça n'est pas très cohérent, mais issu de l'historique et 
surtout de la longue période où l'on avait ces noeuds mais pas encore 
les limites des communes.


Ils ne servent pas qu'à ça, mais c'est quand même l'usage le plus courant.

Est-ce à dire :
- que l'information devrait plutôt être portée par la relation ?
- que les nœuds en question devraient toujours faire partie d'une 
relation avec pour rôle label ?


Attention, village = 1000 à 10 000 h selon le wiki anglophone mais juste 
moins de 10 000 en VF.
hamlet = moins de 100-200 en anglais et en français (entre 200 et 1 000 
on en fusille jusqu'à se ramener au cas précédent - méthode (C) par un 
oculiste de Damas ?)

Pour être cohérent village = 200 à 10 000 ?

Quand dans une commune il y a des noyaux urbains, le "place" de la 
commune c'est pour la totalité des habitants de la commune ou, mettons 
que suite à une réunification deux communes soient devenues une seule, 
le place de la nouvelle commune tient compte de la population globale 
mais le place de chaque ancienne commune (à supposer des noyaux urbains) 
tient compte de la partie agglomérée de l'ancienne commune donc on 
"double" les habitants sur la zone ?


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

Re: [OSM-talk-fr] eaux intérieures (était Image of the week)

2016-02-10 Par sujet Jérôme Amagat 
Les changements date d'il y a 25 ans  et rien n'est imposé.
Sinon je pense que c'est faut décrire Ile-de-Sein c'est un nom propre qui
ne doit avoir qu'une orthographe.

Le mercredi 10 février 2016, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

> Le 10 févr. 2016 à 23:22, osm.sanspourr...@spamgourmet.com 
> a écrit
> > (*) vous avez vu, l'ile a perdu son accent circonflexe, pour le nom de
> l'Île-de-Sein il faut un décret ou on doit mettre name= et
> old_name=Île-de-Sein ?). Autre solution sur tout fr:name remplacer à
> l'affichage les Î par des I.
>
> Je suppose que c'est de l'humour : Le décret n'impose à personne de
> changer la moindre façon d'écrire. Les nouveautés ne seront plus
> sanctionnables lors des examens officiels.
> Quant à l'INSEE, elle continuera comme avant sans rien changer aux noms de
> lieu, dont elle a la garde.
>
> C.
> ___
> 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] amenity=townhall et place=village à séparer ?

2016-02-10 Par sujet Jérôme Amagat 
Le jeudi 11 février 2016, > a
écrit :

> Le 10/02/2016 22:24, Nicolas Moyroud - nmoyr...@free.fr a écrit :
>
> D'ailleurs les nœud place=village ne devrai je pense n'être accrocher a
> rien.
>
> En théorie oui, en pratique à vérifier.
> J'ai vu des moteurs de routage ne pas savoir aller à un endroit parce
> qu'il était à 5 m de la route sans chemin piéton pour y aller.
>

Le probleme vient plutot du moteur de routage dans ce cas. :)



>
>
>
> Le 10/02/2016 22:27, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Ces noeuds place=* servent plus ou moins de role de label pour les
> relations définissant les limites des communes.
>
> En fait tout ça n'est pas très cohérent, mais issu de l'historique et
> surtout de la longue période où l'on avait ces noeuds mais pas encore les
> limites des communes.
>
> Ils ne servent pas qu'à ça, mais c'est quand même l'usage le plus courant.
>
> Est-ce à dire :
> - que l'information devrait plutôt être portée par la relation ?
> - que les nœuds en question devraient toujours faire partie d'une relation
> avec pour rôle label ?
>
> Attention, village = 1000 à 10 000 h selon le wiki anglophone mais juste
> moins de 10 000 en VF.
> hamlet = moins de 100-200 en anglais et en français (entre 200 et 1 000 on
> en fusille jusqu'à se ramener au cas précédent - méthode (C) par un
> oculiste de Damas ?)
> Pour être cohérent village = 200 à 10 000 ?
>
> Quand dans une commune il y a des noyaux urbains, le "place" de la commune
> c'est pour la totalité des habitants de la commune ou, mettons que suite à
> une réunification deux communes soient devenues une seule, le place de la
> nouvelle commune tient compte de la population globale mais le place de
> chaque ancienne commune (à supposer des noyaux urbains) tient compte de la
> partie agglomérée de l'ancienne commune donc on "double" les habitants sur
> la zone ?
>
> Jean-Yvon
>

>

Moi je dirais qu'il ne faut plus mettre population= sur les place= en
France vu qu'on a un meilleur endroit pour le mettre, les relation commune,
alors que sur un place=Village on ne sais pas si c'est la population de la
commune entière ou bien d'une possible ancienne commune ou du village
seulement. D'ailleurs si je vois ça à l'étranger je me dis que c'est la
population du village.
Vu qu'on a toutes les relations de commune depuis quelques temps je dirais
qu'il ne faut plus utiliser les tags population et ref:Insee ( et peut être
d'autre) sur des place=


Pour la plupart des communes, son nom est le même que la ville ou village
principale, le chef lieu mais après une fusion de communes ou la création
d'une commune nouvelle le nom de la commune peut être bien différent des
villes et village ou être le nom des ancienne commune relié par des tiret.
Dans ces cas, aucun tag place= ne doit avoir comme nom le nom de la commune
vu qu'aucun village ou ville porte ce nom.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr