Re: [OSM-talk-fr] Multipolygone

2020-01-01 Par sujet Vincent de Château-Thierry 
Bonjour,

> De: "Arnaud Champollion" 
> 
> Est-ce que toute relation formée de membres "outer" devrait posséder
> le tag type=multipolygon ?

Non pas forcément
 
> En ce qui nous concerne sur OSMDigne :
> https://www.openstreetmap.org/relation/1046954
> 
> Cette réserve géologique est une relation comprenant 18 polygones
> membres avec le rôle outer. Dès lors, cette relation devrait-elle
> avoir l'attribut type=multipolygon ?

Les relations type=boundary sont un type particulier de multipolygones, et en 
tout cas pour la modélisation des ways membres on s'y prend de la même manière 
que pour un multipolygone classique, avec les rôles "outer" et "inner". Ton 
exemple ici de relation type=boundary est tout à fait valide.

vincent

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

Re: [OSM-talk-fr] Multipolygone

2020-01-01 Par sujet osm . sanspourriel 
Non, boundary est correct : sur le lien que tu as passé tu cliques sur boundary 
(le type de la relation), français et tu arrives sur :

https://wiki.openstreetmap.org/wiki/FR:Relation:boundary

Jean-Yvon

> Bonjour,
> 
> Est-ce que toute relation formée de membres "outer" devrait posséder le 
> tag type=multipolygon ?
> 
> En ce qui nous concerne sur OSMDigne : 
> https://www.openstreetmap.org/relation/1046954


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

[OSM-talk-fr] Multipolygone

2020-01-01 Par sujet Arnaud Champollion 

Bonjour,

Est-ce que toute relation formée de membres "outer" devrait posséder le 
tag type=multipolygon ?


En ce qui nous concerne sur OSMDigne : 
https://www.openstreetmap.org/relation/1046954


Cette réserve géologique est une relation comprenant 18 polygones 
membres avec le rôle outer. Dès lors, cette relation devrait-elle avoir 
l'attribut type=multipolygon ?


Merci

Arnaud


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

Re: [OSM-talk-fr] Besoin d'aide pour le Parc national de Guadeloupe

2020-01-01 Par sujet Jérôme Amagat 
Le mer. 1 janv. 2020 à 17:27, Yves P.  a écrit :

>
> Il semble que tu n'as pas compris comment fonctionne ces polygones et même
> s'ils portent le même "nom" ils ont des attributs différents pour
> différentes choses homonymes et ne couvrant pas la même chose (département
> ou région, commune ou arrondissement ou canton ou circonscription
> législative ou académie ou île...). Chacune joue un rôle parmi les autres
> de même type.
>
> La *question principale* était comment passer de 3 traits de côtes à 1
> seul ?
> 😁Le Parc national doit faire ses relevés à marée basse, le SHOM à marée
> haute et les contributeurs OSM après un Ti’ punch😁
>

Le SHOM c'est marée haute coefficient 120 (le plus haut sans tempête) et
c'est aussi (dans la quasi totalité des cas) la limite des communes, des
départements et des régions.
natural=coastline dans osm c'est pas super clair d’après le wiki
c'est "Mean high water springs" j'ai toujours pas compris si c’était la
moyenne des marées hautes ( donc un coef 95) ou la moyenne des plus hautes
marées hautes donc coef 120 comme le SHOM.
Pour les parc régionaux, c'est un regroupement de commune donc je dirais
que c'est la même limite que les communes mais pour les parcs nationaux, je
ne sais pas :(


>
> La *question secondaire* portait effectivement sur ces polygones
> homonymes :
>
> J’avoue, j’ai regardé uniquement et rapidement les relations Bouillante
>  
> (commune)
> et Bouillante (canton de Saint-Rose-1)
> 
> Le découpage du canton me paraissait bizarre à vu d’oeil dans sa partie
> sud.
>

erreur assez fréquente (j'annule des changements de temps en temps), penser
que la relation du canton qui porte le nom d'une commune (c'est presque
partout le cas) est là pour représenter une commune. c'est 2 chose
distinctes même si le nom est le même. Là c'est un peu différent, c'est une
relation pas pour le canton mais pour la parti d'une commune qui fait parti
d'un canton, je n'aime pas bien c'est relation, je trouve que la relation
du canton suffit, et si l'on veux retrouver cette parti du canton on a les
relation des communes, c'est Philippe Verdy qui a créé ces relations un peu
partout en france.

>
> Pour les relations Guadeloupe, 2 semblent avoir la même géométrie (1047206
> 
>  et 2562137
> )
> avec des admin_level respectivement de 6 et 4.
> La 3eme (7109289
> ) 
> contient
> uniquement Basse et Grande Terres (sans Marie-Galante, La Désirade et les
> îlets).
>

Une relation pour la région, une pour le département et une pour l'île, en
réalité pas l'île, puisque la Guadeloupe au sens géographique c'est 2 îles
donc cette relation a place=archipelago comme tag et ne contient pas les
autre îles.
Pour la Guadeloupe, il y a toujours une région et un département, mais il y
a plusieurs cas où les 2 ont fusionné en Collectivité territoriale unique
https://fr.wikipedia.org/wiki/Collectivit%C3%A9_territoriale_unique
Pour coller à cette nouvelle réalité, il y a peu être des changements à
faire dans osm. Pour Martinique, Guyane et Mayotte, il n'y a plus de raison
d'avoir de relation admin_level=6. Pour la Corse, c'est différent, il n'y a
plus les 2 départements mais encore les 2 préfectures...

>
> Ma *question secondaire était en fait *: Peut-on définir une seule fois
> la géométrie avec par exemple 1047206
> ,
> et inclure cette relation dans 2562137
>  ?
> Ainsi, on se retrouve avec moins de relations au niveau d’une ligne de
> côte par exemple.
> Ça me semble plus simple à comprendre et plus simple à maintenir ?
>
> Et de même, la relation Guadeloupe pourrait contenir uniquement les
> relations Grande-Basse-Terre, Terre de Bas, Terre de Haut… ??
>

Non c'est pas l'usage dans osm, il faut rappeler tous les way dans toutes
les relations.

>
> —
> Yves
>
> Je viens de regarder le découpage du canton de Saint-Rose-1 par rapport au
> texte officiel : ça colle vaguement.
>
> Soit l’import ? d’origine est trop simplifié, soit le polygone a été abimé.
> Il semble que ce soit le premier cas d’après cette requête overpass
>  (pas de changement visible depuis 3
> ans).
>
> *3° La partie de la commune de Bouillante située au nord d'une ligne
> définie par l'axe des voies et limites suivantes : depuis le littoral
> occidental, rivière Celleron, route de la Lézarde (direction Sud-Ouest),
> rue René-Turlet (direction Sud), rue Maurice-Selbonne (direction Sud-Est),
> chemin Deravin, segment de 89 mètres reliant les deux points de longitude
> et latitude respectives 633561,35/17

[OSM-talk-fr] Casemate

2020-01-01 Par sujet Muselaar 

Bonsoir,

J'ai cherché dans le wiki, je n'ai rien trouvé…

Comment doit-on taguer un bâtiment qui est partiellement enterré ? Comme 
une habitation troglodyte ? En l'occurrence, il s'agit d'une ancienne et 
grande casemate, reconvertie en bâtiment public. Il me semble que c'est 
pourtant assez courant. L'intérieur est au niveau du sol par devant, 
mais le toit est sous 1 ou 2 m de terre, avec de la végétation dessus, 
en continuité avec le sol sur les côtés et le derrière. En quelque 
sorte, c'est comme à flanc de coteau sur 3 côtés. Seule la façade est 
dégagée, tout le reste est enterré. Et au dessus, il y a des chemins qui 
passent, des arbres qui poussent…


Faut-il mettre level -1 ? c'est juste par rapport au sol qui est dessus, 
mais pas par rapport au sol qui est devant…


Location=underground ? C'est pas ça non plus, puisque la façade est 
normale, comme de n'importe quelle maison.


Rien mettre de spécial ? C'est encore plus faux.

Bref, comment faire ?

Bonne année à tous !

Muselaar


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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: clairière dans une forêt

2020-01-01 Par sujet Arnaud Champollion 

Le 22/12/2019 à 23:25, osm.sanspourr...@spamgourmet.com a écrit :


Sinon si tu connais le numéro de la relation, tu charges juste la 
relation.


Soit en r+le numéro de la relation dans CTRL+MAJ+O soit par une 
requête overpass.




Ça y est j'ai compris et réussi à créer le multipolygone avec la méthode 
du CTRL+MAJ+O :


https://www.openstreetmap.org/way/757914576#map=19/44.08399/6.23167

Merci



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

Re: [OSM-talk-fr] barrier=block infranchissable à vélo malgré bicycle=yes

2020-01-01 Par sujet JB 

Oups, avec le lien, ça va mieux :
https://brouter.damsy.net/latest/#map=17/48.80057/2.35349/standard&lonlats=2.351096,48.801974;2.353424,48.799585

Le 01/01/2020 à 20:37, JB via Talk-fr a écrit :

Euh, chez moi, il le prend bien.
Mais sur ton exemple, il préfère juste passer par ailleurs. Les goûts 
et les couleurs…

JB.

Le 01/01/2020 à 19:48, Shohreh a écrit :

Ça ne plait pas à BRouter, d'où ma question.

https://brouter.damsy.net/latest/#map=17/48.80017/2.35421/standard,Route%20quality%20coding&lonlats=2.351096,48.801974;2.355012,48.7982 





--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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





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





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

Re: [OSM-talk-fr] barrier=block infranchissable à vélo malgré bicycle=yes

2020-01-01 Par sujet JB via Talk-fr 

Euh, chez moi, il le prend bien.
Mais sur ton exemple, il préfère juste passer par ailleurs. Les goûts et 
les couleurs…

JB.

Le 01/01/2020 à 19:48, Shohreh a écrit :

Ça ne plait pas à BRouter, d'où ma question.

https://brouter.damsy.net/latest/#map=17/48.80017/2.35421/standard,Route%20quality%20coding&lonlats=2.351096,48.801974;2.355012,48.7982



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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





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

Re: [OSM-talk-fr] absence de BAN dans BANO

2020-01-01 Par sujet osm . sanspourriel 
> Et sinon je vois que personne n'a encore souhaité de BAN année. Voilà, 
> c'est fait, désolé, on peut passer à autre chose /o\
> 
> vincent
Et pour les amateurs de contrepèteries compatibles OSM dès à présent :
BANO née


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

Re: [OSM-talk-fr] barrier=block infranchissable à vélo malgré bicycle=yes

2020-01-01 Par sujet Shohreh 
Ça ne plait pas à BRouter, d'où ma question.

https://brouter.damsy.net/latest/#map=17/48.80017/2.35421/standard,Route%20quality%20coding&lonlats=2.351096,48.801974;2.355012,48.7982



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] barrier=block infranchissable à vélo malgré bicycle=yes

2020-01-01 Par sujet David Crochet 

Bonjour

Je ne vois pas le problème :

https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=48.80060%2C2.35237%3B48.80103%2C2.35198#map=19/48.80082/2.35217

Cordialement

--
David Crochet


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

[OSM-talk-fr] barrier=block infranchissable à vélo malgré bicycle=yes

2020-01-01 Par sujet Shohreh 
Bonjour,

Ces blocs suffisent à empêcher le routeur BRouter à faire passer par là,
bien qu'il est taggé comme bicycle=yes et qu'il est physiquement ouvert aux
vélos :

https://postimg.cc/c6pzxj4p
https://www.openstreetmap.org/node/3054030093#map=17/48.80070/2.35339

Je sais bien qu'il ne faut pas tagger en fonction des routeurs, mais… est-ce
la bonne façon de tagger ?

Merci.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] absence de BAN dans BANO

2020-01-01 Par sujet Vincent de Château-Thierry 

Bonjour,

Le 31/12/2019 à 19:02, deuzeffe a écrit :


C'était bien pour préparer le terrain, dans cette optique, que toi et 
tes acolytes (dont les noms m'échappent pour l'heure - ybon ?) avez 
relancé un osm-vs-fantoir digne de la 3e décennie du 3e millénaire, non 
? Ou alors osm-vs-fantoir=BANOv2 ?


A vrai dire moyennement. Comme l'a rappelé Christian, on a 
volontairement laissé du champ à la BAN pendant plusieurs années. La v2 
de BANO a surtout été motivée par l'arrivée du cadastre d'Etalab et 
l'opportunité qu'il offrait pour ne plus dépendre du scrapping des PDFs 
de cadastre.gouv.fr, comme évoqué ici récemment. On passait aussi à une 
source (de simples CSV) bien plus simple à manipuler, nu code plus 
facile à partager, etc. Cette période a coïncidé avec la fin des années 
de fusions massives de communes, qui mettaient bien le souk dans nos 
référentiels et rendaient la maintenance hasardeuse.


La BAN en LO arrive et on va bien sûr s'en emparer, pour obtenir ce 
qu'on évoque depuis longtemps avec Christian, à savoir une tentative de 
meilleur de tous les mondes : un mix Cadastre brut, BAN, BALs des 
collectivités en LO ou ODbL, et OSM bien sûr. L'idée est d'avoir le plus 
de sources possible et de les organiser par ordre de priorité pour 
essayer de puiser pour chaque adresse la source la plus qualitative, 
précise, à jour, et sortir quotidiennement le listing des 20 millions et 
quelques d'adresses à l'échelle nationale, qui réponde à un besoin, dans 
la lignée de la BANO actuelle. La priorité des sources est à établir 
avec l'arrivée de la BAN, mais jusque là l'idée a toujours été de 
privilégier OSM. Pas de raison que ça change tant qu'aucune autre source 
ne permettra de mise à jour aussi rapide.


Pour s'y retrouver dans le code :
https://github.com/osm-fr/bano/tree/packaging est le repo du code qui 
tourne chaque nuit à partir de minuit et qui constitue le jeu de données 
BANO. C'est déployé sur la VM osm162 d'OSM-FR. C'est littéralement "BANO 
v2". Le résultat pour un consommateur de BANO ce sont des fichiers CSV, 
shapefile, json ou ttl. Pour l'instant ceux de BANO v2 ne sont pas 
encore disponibles, c'est le boulot du moment que de les mettre au 
point. En attendant, ceux de BANO v1 sont accessibles ici : 
http://bano.openstreetmap.fr/data/


https://github.com/osm-fr/osm-vs-fantoir est le code correspondant à 
tout ce qui se consulte sur les adresses commençant par 
https://dev.cadastre.openstreetmap.fr/fantoir/ Ca s'appuie intégralement 
sur les bases de données de BANO v2. On peut voir ce site comme la 
vitrine de contribution OSM de BANO. Je sais pas si c'est clair...


Et sinon je vois que personne n'a encore souhaité de BAN année. Voilà, 
c'est fait, désolé, on peut passer à autre chose /o\


vincent

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

Re: [OSM-talk-fr] Besoin d'aide pour le Parc national de Guadeloupe

2020-01-01 Par sujet Philippe Verdy 
>
> Pour les relations Guadeloupe, 2 semblent avoir la même géométrie (1047206
> 
>  et 2562137
> )
> avec des admin_level respectivement de 6 et 4.
> La 3eme (7109289
> ) 
> contient
> uniquement Basse et Grande Terres (sans Marie-Galante, La Désirade et les
> îlets).
>
> Ma *question secondaire était en fait *: Peut-on définir une seule fois
> la géométrie avec par exemple 1047206
> ,
> et inclure cette relation dans 2562137
>  ?
>

Non. Les ways doivent être présentes dans les relations frontières, même si
ce sont les mêmes membres (car effectivement la région et le département se
partagent le même territoire ; la Guadeloupe n'a pas fusionné ses deux
collectivités, elle s'y est opposée par référendum local, donc deux
entités, deux objets, deux niveaux adminsitratifs poru que l'ensemble des
régions et celui des départements soit complet en France).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Besoin d'aide pour le Parc national de Guadeloupe

2020-01-01 Par sujet Yves P. 

> Cartographie bitmap du Zonage de la réserve de biosphère datant de 10 ans
> http://documentation.guadeloupe-parcnational.fr/IMG/pdf/14030409_modifiee.pdf 
> 
> 
> Avez-vous un fichier vectoriel récent et officiel qui correspond à ça ?

J’ai fini par trouver dans la jungle du http://www.geocatalogue.fr : les liens 
sont cassés vers la couche WMS.

En cherchant directement dans KaruGéo 
 
(Le portail d'informations géographiques de la Guadeloupe), j’ai trouvé les 
Limites des zones classées coeurs du Parc national de la Guadeloupe 

Elle a été importée directement dans OSM, d’où la duplication de la ligne de 
côte.
C’est probablement le cas pour les Limites de la zone classée Aire maritime 
adjacente (AMA) du Parc national de la Guadeloupe 
 d’où un 3e trait de 
côte.

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

Re: [OSM-talk-fr] Besoin d'aide pour le Parc national de Guadeloupe

2020-01-01 Par sujet Yves P. 

> Il semble que tu n'as pas compris comment fonctionne ces polygones et même 
> s'ils portent le même "nom" ils ont des attributs différents pour différentes 
> choses homonymes et ne couvrant pas la même chose (département ou région, 
> commune ou arrondissement ou canton ou circonscription législative ou 
> académie ou île...). Chacune joue un rôle parmi les autres de même type.
La question principale était comment passer de 3 traits de côtes à 1 seul ?
😁Le Parc national doit faire ses relevés à marée basse, le SHOM à marée haute 
et les contributeurs OSM après un Ti’ punch😁

La question secondaire portait effectivement sur ces polygones homonymes :

J’avoue, j’ai regardé uniquement et rapidement les relations Bouillante 
 
(commune) et Bouillante (canton de Saint-Rose-1) 

Le découpage du canton me paraissait bizarre à vu d’oeil dans sa partie sud.

Pour les relations Guadeloupe, 2 semblent avoir la même géométrie (1047206 
 et 
2562137 
) avec 
des admin_level respectivement de 6 et 4.
La 3eme (7109289 
) 
contient uniquement Basse et Grande Terres (sans Marie-Galante, La Désirade et 
les îlets).

Ma question secondaire était en fait : Peut-on définir une seule fois la 
géométrie avec par exemple 1047206 
, et 
inclure cette relation dans 2562137 
 ?
Ainsi, on se retrouve avec moins de relations au niveau d’une ligne de côte par 
exemple.
Ça me semble plus simple à comprendre et plus simple à maintenir ?

Et de même, la relation Guadeloupe pourrait contenir uniquement les relations 
Grande-Basse-Terre, Terre de Bas, Terre de Haut… ??

—
Yves

Je viens de regarder le découpage du canton de Saint-Rose-1 par rapport au 
texte officiel : ça colle vaguement.

Soit l’import ? d’origine est trop simplifié, soit le polygone a été abimé.
Il semble que ce soit le premier cas d’après cette requête overpass 
 (pas de changement visible depuis 3 ans).

3° La partie de la commune de Bouillante située au nord d'une ligne définie par 
l'axe des voies et limites suivantes : depuis le littoral occidental, rivière 
Celleron, route de la Lézarde (direction Sud-Ouest), rue René-Turlet (direction 
Sud), rue Maurice-Selbonne (direction Sud-Est), chemin Deravin, segment de 89 
mètres reliant les deux points de longitude et latitude respectives 
633561,35/1785007,97 et 633628,05/1785063,56 (direction Nord-Est), chemin sans 
nom correspondant à la ligne de 838 mètres reliant les quatre points de 
longitude et latitude respectives 633628,05/1785063,56, 633827,55/1784854,03, 
633919,77/1784811,69 et 634266,47/1784816,11, rivière Bourceau (direction 
Sud-Est), cours d'eau Ravine-Concession, segment de 548 mètres reliant les deux 
points de longitude et latitude respectives 635100,12/1783623,18 et 
635642,20/1783540,00, prolongé jusqu'à la limite territoriale de la commune de 
Vieux-Habitants.
Le bureau centralisateur de ce canton est le bureau centralisateur de la 
commune de Sainte-Rose.


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

Re: [OSM-talk-fr] Défusion de commune

2020-01-01 Par sujet Philippe Verdy 
il manque le end_date pour désambiguiser le tout (même si on a ":disused"
en préfixe, on ne sait pas depuis quand alors qu'on a un "start_date"
récent)

Le mer. 1 janv. 2020 à 01:22, Donat ROBAUX  a écrit :

> Ca y est c'est fait. Vous m'excuserez de l'avoir fait en 3 changeset, mais
> je
> voulais faire ca propre:
> https://www.openstreetmap.org/changeset/79071173
> https://www.openstreetmap.org/changeset/79071176
> https://www.openstreetmap.org/changeset/79071178
>
> Vous avez le droit de jeter un œil pour voir si c'est bien fait. Pour
> l'ancienne "commune nouvelle", à voir si on laisse comme ca ou pas. La
> situation est peu fréquente. Je ne sais pas ce qui a été fait pour les
> autres cas qui se sont présentés.
>
> On va pouvoir faire un tweet en disant qu'on est les seuls à jour!
>
> Donat
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Besoin d'aide pour le Parc national de Guadeloupe

2020-01-01 Par sujet Philippe Verdy 
Il semble que tu n'as pas compris comment fonctionne ces polygones et même
s'ils portent le même "nom" ils ont des attributs différents pour
différentes choses homonymes et ne couvrant pas la même chose (département
ou région, commune ou arrondissement ou canton ou circonscription
législative ou académie ou île...). Chacune joue un rôle parmi les autres
de même type.

Ce n'est pas spécifique à la Guadeloupe, c'est partout comme ça. Il ne
suffit pas de regarder le nom affiché de façon simplifiée dans l'éditeur.

Sinon cette réserve est inclus dans la réserve Agora (comme tout le domaine
maritime de Martinique, Guadeloupe, Saint-Martin et Saint-Barth), laquelle
comprend aussi les autres parcs marins régionaux et les réserves (les parcs
se superposent, partiellement, mais pas pour protéger les mêmes choses).


Le mer. 1 janv. 2020 à 10:15, Yves P.  a écrit :

> Bonjour,
>
> Je vous souhaite une année 2020 riche en projets cartographiques 😊
> Je ne suis pas inquiet, le travail sur OSM est sans fin 😁
>
> Hier, je me suis cassé les dents à la Guadeloupe sur ce qui semblait une
> « simple » relation multi polygone : la Réserve Cousteau
>  à
> l’ouest de la Guadeloupe.
> Ce petit triangle est en fait un bout du coeur du Parc national de
> Guadeloupe
> .
>
> Ça se complique un peu car ce bout (toute le parc en fait) est exclu de l'Aire
> d'adhésion du Parc national de Guadeloupe
> .
> Il y a encore une subtilité (pas claire pour moi), il semble aussi exclu
> (ou fait partie ?) de l'Aire de coopération de la réserve de biosphère de
> l'archipel de Guadeloupe
> .
>
> Ce qui est compliqué, c’est qu’il n’y a pas un « beau » découpage des
> limites avec des multi polygones, mais une superposition de plusieurs
> polygones, plus ou moins précis, avec plusieurs multi polygones.
>
> Et cerise sur le gâteau, "LE" trait de côte (3 lignes vaguement
> superposées) appartient aussi à 15 multi polygones !!!
> https://www.openstreetmap.org/way/41876263#map=19/16.17419/-61.77964
> https://www.openstreetmap.org/way/70810249#map=19/16.17449/-61.77961
> https://www.openstreetmap.org/way/70483697#map=19/16.17427/-61.78038
>
> Bref, en essayant de simplifier ça (supprimer 2 polygones en n’utilisant
> que le trait de côte), je me suis retrouvé avec toutes les relations
> cassées, plusieurs plantages de JOSM et fort heureusement, l’impossibilité
> d’envoyer ma demi journée de travail sur le serveur.
>
> Question : peut-on inclure des frontières dans frontières ?
> Le (multi) polygone Réserve Cousteau serait défini une seule fois, inclus
> dans le Parc (outer), inclus dans l’Aire d’adhésion (inner)…
>
> Il y a probablement d’autres simplifications à faire ?
> • 3 relations Guadeloupe (2562137, 1047206 et 7109289)
> • 2 relations Basse-Terre (1694553 et 7109289)
> • 2 relations Bouillante (5837164 et 278474) ?
>
> Avez-vous des conseils pour simplifier ça ?
> Dans quel ordre procéder…
>
> —
> Yves
>
> Cartographie bitmap du Zonage de la réserve de biosphère datant de 10 ans
>
> http://documentation.guadeloupe-parcnational.fr/IMG/pdf/14030409_modifiee.pdf
>
> Avez-vous un fichier vectoriel récent et officiel qui correspond à ça ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] License ouverte etalab osm et sources (était: absence de BAN dans BANO)

2020-01-01 Par sujet ades 
Pour une fois que je comprends enfin quelque chose à cette question de 
l’utilisation de la  licence ouverte, merci. 

Reste une question au sujet de la source : 
elle doit être indiquée sur chaque objet créé ou modifié à partir d’un doc sous 
LO ? dans un tag ‘ source=* ; ## ‘  et non dans les commentaires du changeset, 
comme je crois l’avoir lu ici il y a quelques temps ?


> Le 1 janv. 2020 à 09:24, Christian Quest  a écrit :
> 
> Le mar. 31 déc. 2019 à 16:51, marc marc  > a écrit :
> Le 31.12.19 à 15:51, Christian Quest a écrit :
> > la BAN sera dispo "avant la fin de l'année" sous Licence Ouverte, donc
> > compatible avec l'ODbL d'OSM et de BANO.
> 
> je n'ai pourtant pas encore commencé le réveillon.
> mais depuis quand l'obligation d'attribution de la LO est compatible
> avec l'absence d'attribution des sources contribuant à osm ?
> si j'affiche la carte d'un changeset provenant d'une source LO,
> il y a pas d'attribution "donnée venant de cette source LO"
> c'est pour cela qu'il me semblait qu'on devait se farcir
> des demandes d'exeption pour que la source accepte de renoncer
> à l'attribution et se contente d'être mentionné dans les sources
> contribuant à osm
> 
> Je suis en tout cas ravi si la BANOv2 ou v3 (surtout ses outils
> à la contribution osm) incluera la BAN en dernier resort.
> 
> TL;DR: La LO est compatible avec l'ODbL et OSM et depuis toujours.
> 
> Que dit la LO ?
> 
> Obligation de: "mentionner la paternité de l’«Information»: sa source (au 
> moins le nom du «Concédant») et la date de dernière mise à jour de 
> l’«Information» réutilisée."
> Le tag source suffit pour cela lorsque la donnée est insérée dans la base 
> OSM, surtout sur l'aspect millésime.
> 
> On s'est surtout posé la question sur la "non altération/dénaturation" prévue 
> par la Loi qui est plus précise:
> 
> "Sauf accord de l'administration, la réutilisation des informations publiques 
> est soumise à la condition que ces dernières ne soient pas altérées, que leur 
> sens ne soit pas dénaturé et que leurs sources et la date de leur dernière 
> mise à jour soient mentionnées." - L322-1 du CRPA
> 
> Pour OSM c'est le versioning et toute notre historisation qui permet d'être 
> transparent sur les "altérations", souvent pour améliorer la donnée 
> d'ailleurs.
> 
> En fait, la Loi cherche à préserver la version authentique (ne pas faire 
> passer comme donnée officielle quelque chose qui aurait été modifié), mais 
> cela ne concerne pas les réutilisations. Il y a aussi un autre concept 
> derrière ce mot "dénaturé": ne pas faire dire n'importe quoi à l'information 
> publique, avec une jurisprudence claire dessus (infos nutritionnelles 
> présentées de façon trompeuses par une chaîne de fast-food qui a été 
> condamnée).
> 
> Il y a même eu une analyse juridique faite à Etalab sur la compatibilité de 
> la LO avec un versement dans wikidata (CC0). Résultat: tant que la source et 
> le millésime sont indiqués au moment de LA réutilisation initiale (le 
> versement dans wikidata), c'est conforme à la LO, la Loi et l'esprit général.
> LES réutilisations ultérieures ce cette réutilisation initiales n'ont pas 
> besoin de préserver l'attribution, car ce sont des réutilisations de wikidata 
> (ou OSM dans notre cas).
> 
> Un LA ou un LES dans la Loi ça a des conséquences qu'on n'imagine pas ;)
> 
> -- 
> 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] Tag PMU ?

2020-01-01 Par sujet Xavier Rolland Larher 
Bonjour à tous,

Tu peux toujours mettre:
gambling=betting...
 
PMU c'est une notion très francophone.

Est ce qu'on pourrait le noter dans le wiki comme une possibilité de 
représenter les PMU? Je m'étais déjà posé la question,  et plein d'autres ont 
du se la poser. Même si cela n'est pas parfait, ça permettrait d'avoir une 
directive d'étiquetage claire.

À moins qu'il n'y ait une meilleure solution ?

A+



-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Besoin d'aide pour le Parc national de Guadeloupe

2020-01-01 Par sujet Yves P. 
Bonjour,

Je vous souhaite une année 2020 riche en projets cartographiques 😊
Je ne suis pas inquiet, le travail sur OSM est sans fin 😁

Hier, je me suis cassé les dents à la Guadeloupe sur ce qui semblait une « 
simple » relation multi polygone : la Réserve Cousteau 
 à l’ouest 
de la Guadeloupe.
Ce petit triangle est en fait un bout du coeur du Parc national de Guadeloupe 
.

Ça se complique un peu car ce bout (toute le parc en fait) est exclu de l'Aire 
d'adhésion du Parc national de Guadeloupe 
.
Il y a encore une subtilité (pas claire pour moi), il semble aussi exclu (ou 
fait partie ?) de l'Aire de coopération de la réserve de biosphère de 
l'archipel de Guadeloupe 
.

Ce qui est compliqué, c’est qu’il n’y a pas un « beau » découpage des limites 
avec des multi polygones, mais une superposition de plusieurs polygones, plus 
ou moins précis, avec plusieurs multi polygones.

Et cerise sur le gâteau, "LE" trait de côte (3 lignes vaguement superposées) 
appartient aussi à 15 multi polygones !!!
https://www.openstreetmap.org/way/41876263#map=19/16.17419/-61.77964
https://www.openstreetmap.org/way/70810249#map=19/16.17449/-61.77961
https://www.openstreetmap.org/way/70483697#map=19/16.17427/-61.78038

Bref, en essayant de simplifier ça (supprimer 2 polygones en n’utilisant que le 
trait de côte), je me suis retrouvé avec toutes les relations cassées, 
plusieurs plantages de JOSM et fort heureusement, l’impossibilité d’envoyer ma 
demi journée de travail sur le serveur.

Question : peut-on inclure des frontières dans frontières ?
Le (multi) polygone Réserve Cousteau serait défini une seule fois, inclus dans 
le Parc (outer), inclus dans l’Aire d’adhésion (inner)…

Il y a probablement d’autres simplifications à faire ?
• 3 relations Guadeloupe (2562137, 1047206 et 7109289)
• 2 relations Basse-Terre (1694553 et 7109289)
• 2 relations Bouillante (5837164 et 278474) ?

Avez-vous des conseils pour simplifier ça ?
Dans quel ordre procéder…

—
Yves

Cartographie bitmap du Zonage de la réserve de biosphère datant de 10 ans
http://documentation.guadeloupe-parcnational.fr/IMG/pdf/14030409_modifiee.pdf

Avez-vous un fichier vectoriel récent et officiel qui correspond à ça ?

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

Re: [OSM-talk-fr] absence de BAN dans BANO

2020-01-01 Par sujet Christian Quest 
Le mar. 31 déc. 2019 à 16:51, marc marc  a
écrit :

> Le 31.12.19 à 15:51, Christian Quest a écrit :
> > la BAN sera dispo "avant la fin de l'année" sous Licence Ouverte, donc
> > compatible avec l'ODbL d'OSM et de BANO.
>
> je n'ai pourtant pas encore commencé le réveillon.
> mais depuis quand l'obligation d'attribution de la LO est compatible
> avec l'absence d'attribution des sources contribuant à osm ?
> si j'affiche la carte d'un changeset provenant d'une source LO,
> il y a pas d'attribution "donnée venant de cette source LO"
> c'est pour cela qu'il me semblait qu'on devait se farcir
> des demandes d'exeption pour que la source accepte de renoncer
> à l'attribution et se contente d'être mentionné dans les sources
> contribuant à osm
>
> Je suis en tout cas ravi si la BANOv2 ou v3 (surtout ses outils
> à la contribution osm) incluera la BAN en dernier resort.
>

TL;DR: La LO est compatible avec l'ODbL et OSM et depuis toujours.

Que dit la LO ?

Obligation de: "mentionner la paternité de l’«Information»: sa source (au
moins le nom du «Concédant») et la date de dernière mise à jour de
l’«Information» réutilisée."
Le tag source suffit pour cela lorsque la donnée est insérée dans la base
OSM, surtout sur l'aspect millésime.

On s'est surtout posé la question sur la "non altération/dénaturation"
prévue par la Loi qui est plus précise:

"Sauf accord de l'administration, la réutilisation des informations
publiques est soumise à la condition que ces dernières ne soient pas
altérées, que leur sens ne soit pas dénaturé et que leurs sources et la
date de leur dernière mise à jour soient mentionnées." - L322-1 du CRPA

Pour OSM c'est le versioning et toute notre historisation qui permet d'être
transparent sur les "altérations", souvent pour améliorer la donnée
d'ailleurs.

En fait, la Loi cherche à préserver la version authentique (ne pas faire
passer comme donnée officielle quelque chose qui aurait été modifié), mais
cela ne concerne pas les réutilisations. Il y a aussi un autre concept
derrière ce mot "dénaturé": ne pas faire dire n'importe quoi à
l'information publique, avec une jurisprudence claire dessus (infos
nutritionnelles présentées de façon trompeuses par une chaîne de fast-food
qui a été condamnée).

Il y a même eu une analyse juridique faite à Etalab sur la compatibilité de
la LO avec un versement dans wikidata (CC0). Résultat: tant que la source
et le millésime sont indiqués au moment de LA réutilisation initiale (le
versement dans wikidata), c'est conforme à la LO, la Loi et l'esprit
général.
LES réutilisations ultérieures ce cette réutilisation initiales n'ont pas
besoin de préserver l'attribution, car ce sont des réutilisations de
wikidata (ou OSM dans notre cas).

Un LA ou un LES dans la Loi ça a des conséquences qu'on n'imagine pas ;)

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