Re: [OSM-talk-fr] les différents name:xx

[Philippe Verdy]

Le jeu. 31 janv. 2019 à 17:19, marc marc  a
écrit :

> Le 31.01.19 à 16:06, Francois Gouget a écrit :
> > divergence entre la relation boundary d'une ville
> > https://www.openstreetmap.org/relation/2098985
>
> heu non, ce n'est pas la relation de la ville mais de la commune.
> ils ont le même nom mais c'est 2 choses totalement différent.
>
> > wikipedia pourrait être utilisé pour identifier les traduction
> manquantes.
>
> c'est le sens du plugin wikidata dans josm même si son ergonomie est
> améliorable.
>
> > probablement des problèmes de performance).
>
> cela pose surtout un problème de licence (même si wikidata lui-même
> est cc, tu peux injecter n'importe quelle licence dans wikidata
> et pour wikipedia/wikidata.
> c'est d'ailleurs mis en grand sur la page du wiki concernée
> https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia
>
> Précision essentielle, Wikidata est CC0, usage libre sans contrainte,
c'est pratiquement du domaine public mais avec une origine connue (si on
veut la vérifier et on arrive à retrouver cette référence). Ce n'est pas du
CCBYSA comme Wikipedia qui est incompatible avec l'ODbL.

Mais le gros problème est qu'une grande partie de Wikidata a été importée
massivement par des bots depuis Wikipedia (ou les autres wikis de Wikimedia
sous la même licence), sans rien demander aux auteurs originaux et sans les
citer (l'attribution de source est souvent omise, voire incorrecte ou en
tout cas insuffisante si elle ne mentionne que Wikipedia sans lien avec les
pages concernées avec leurs auteurs).

De fait la licence CC0 de Wikidata est douteuse, une grande partie des
données étant en fait toujours sous licence initiale CCBYSA. Et on ne sait
pas comment faire le tri. Ne sont sous licence CC0 que les données qui ont
été éditées directement sur Wikidata sans aucun import par un bot, on peut
faire un tri partiel en cherchant l'auteur des modifs sur chaque attribut
(tous les attributs d'un objet n'ont pas la même origine); certains
proviennent aussi de dérivation d'éléments Wikidata importés sous CCBYSA,
pour produire des déclarations à partir d'un bot prenant sa source sur
Wikidata et portant le résultat dessus.

Ceci dit nombre des données importées initialement d'une édition de
Wikipédia sont largement modifiées ensuite par souvent ambigues. NE reste
dans les déclarations alors que les liens des sujets vers les articles
Wikipédia "correspondants" (plus ou moins liés au sujet, mais pas
nécessairement uniques car les articles peuvent porter sur plusieurs
éléments Wikidata réunis et pas forcément les mêmes réunions entre les
diverses éditions linguistiques liées).

En tant que tel les déclarations de liens vers Wikipédia depuis Wikidata ne
sont qu'indicatives et approchantes, pas de vraies affirmation (on ne peut
pas faire d'inférence dessus et surtout pas entre les différentes éditions
linguistiques affichées).

Je pense qu'au delà de ces imports massifs initiaux de Wikiépdia vers
Wikidata, les ambiguités sont telles que de nombreux éléments ont été
redéfinis et mieux précisés pour devenir plus indépendants des contenus
d'articles particuliers sur une édition particulière de Wikipédia (mais
pour beaucoup la structure adoptée vient souvent écraser celle faite à
partir de la version anglophone même si ce n'est pas la plus pertinente sur
un sujet, notamment les sujets fortement géographiquement,
linguistiquement, ou culturellement liés) et cela aboutit parfois à des
aberrations et des contradictions nouvelles avec ce qui était parfaitement
mieux décrit, documenté et structuré dans l'artricle d'origine, là où les
contributeurs de l'éditions anglophone ont voulu faire des approximations
ou des rapprochements un peu abusifs (et difficiles ensuite à annuler quand
l'article anglophone a fait l'objet de décision de fusion). Il s'en suit
alors des difficultés pour les autres éditions à maintenir des distinctions
pourtant claires (mais mal comprises par les anglophones).
Wikidata commence à s'amériorer toutetois en ayant créé des objets
"lexèmes" (liés précisément à une langue de référence) distinct des sujets
confondus par la terminologie. Mais le travail sera long. En attendant la
pertinence des liens Wikipédia indiqués dans les sujets wikidata est
souvent assez peu convaincante (et l'est de moins en moins), mais on butte
sur les terminologies anglophones. Personnellement je trouve que la
classification sur Commons est plus pertinente (au mopins elle est
concertée par une communauté plus large que la seule communauté anglophone
avec ses propres contradictions) car Commons butte nettement moins sur la
terminologie et n'impose pas l'anglais partout comme référence quand il
n'est pas pertinent.

Pourtant les imports massifs de données depuis Wikipédia (notamment
anglophone) continuent vers Wikidata qui ne peut se prévaloir d'une licence
CC0 quand il y a beaucoup trop de données en fait sous licence CCBYSA
d'origine et pas revus après imports d'après l'ontologie et la
classification 

Re: [OSM-talk-fr] Idées rendu des mers

[osm . sanspourriel]

Le 01/02/2019 à 14:57, david.croc...@free.fr a écrit :

Je ne sais pas si cela peut aider à solutionner la problématique, mais je crois qu'en 
météorologie marine, les mers et baies sont découpé en "zones" ou comme ici les 
zones de pêches :
-https://www.lemarin.fr/sites/default/files/styles/full/public/2014/12/11/pavillonfrancecartezonespeche.jpg?itok=PC0Mn4Zl=76778beb2a17c1f15d7d98d3a22f4ecd
-https://media2.labovida.com/11968-thickbox_default/tableau-zone-et-sous-zone-de-peche-60x50cm.jpg?cache=2
-http://www.normandiefraicheurmer.fr/media/carte_fao_zones_de_peche__091139800_1200_08012013.jpg
-http://guidedesespeces.org/fr/zones-de-capture-fao
-http://zeevruchtengids.org/sites/zeevruchtengids.org/files/personen/169FR.jpg
-http://zeevruchtengids.org/sites/zeevruchtengids.org/files/personen/168FR.jpg

Cordialement
-- David Crochet


Pas vraiment, ce que tu donnes ce sont des zones de pêches qui sont un 
découpage un peu arbitraire en pavés, seuls les deux derniers liens sont 
utiles pour voir où positionner des étiquettes.


Le bouquin de l'OMI et le travail de VLIZ, le SHOM néerlandais, que je 
citais dans un message précédent sont plus précis.


Ceci dit, pourquoi ne pas entrer aussi les zones de pêche dans OSM 
(elles sont d'ailleurs aussi sur le site de VLIZ, MarineRegions).


Mais je crains qu'il ne faille comme pour les mers et océans avoir une 
hiérarchie (par exemple Atlantique Nord-Est au dessus de Petite Sole) 
comme Mer d'Iroise est dans Océan Atlantique.


Si pour les zones de pêches je vois bien un "admin_level" pour les mers 
et autres golfes, hormis la surface, je ne vois pas trop selon quel 
critère les afficher. Grosso modo surface de l'ordre d'une région resp. 
d'un département ou d'une commune affichage au même niveau de zoom 
qu'une région, resp. un département ou une commune ?


Sinon il faudrait utiliser la hiérarchie de VLIZ (avec leur accord).

À l'affichage zones de pêche et noms de mers, golfes... sont en 
concurrence : Petite Sole et Mer d'Iroise se recouvrent.


Jean-Yvon

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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Shohreh]

Ok, donc on laisse tomber l'ajout du "oneway:bicycle=no" et on attend que les
outils s'adaptent.

Pas plus mal : ça permettra de continuer à utiliser Id, quand même plus
simple et rapide à utiliser que JOSM juste pour ajouter un tag à un objet.



--
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] Moulinette pour ajouter "oneway:bicycle=no" ?

[althio]

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

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

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

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


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

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

Re: [OSM-talk-fr] Idées rendu des mers

[david . crochet]

Bonjour

- Mail original -
De: "Adrien Grellier" 
À: talk-fr@openstreetmap.org
Envoyé: Vendredi 1 Février 2019 10:09:17
Objet: Re: [OSM-talk-fr] Idées rendu des mers

La difficulté étant de trouver les délimitations précises. 

- Mail original -


Je ne sais pas si cela peut aider à solutionner la problématique, mais je crois 
qu'en météorologie marine, les mers et baies sont découpé en "zones" ou comme 
ici les zones de pêches :
- 
https://www.lemarin.fr/sites/default/files/styles/full/public/2014/12/11/pavillonfrancecartezonespeche.jpg?itok=PC0Mn4Zl=76778beb2a17c1f15d7d98d3a22f4ecd
- 
https://media2.labovida.com/11968-thickbox_default/tableau-zone-et-sous-zone-de-peche-60x50cm.jpg?cache=2
- 
http://www.normandiefraicheurmer.fr/media/carte_fao_zones_de_peche__091139800_1200_08012013.jpg
- http://guidedesespeces.org/fr/zones-de-capture-fao
- http://zeevruchtengids.org/sites/zeevruchtengids.org/files/personen/169FR.jpg
- http://zeevruchtengids.org/sites/zeevruchtengids.org/files/personen/168FR.jpg

Cordialement
-- 
David Crochet

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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Gwenaël Jouvin via Talk-fr]

Bonjour,

En effet Thomas, il y a probablement, à l’origine, une histoire de 
compatibilité et de doublon.

Une page du Wiki décrivait très bien le problème, mais elle a été modifiée 
depuis [1]. Voici le texte qui me servait de référence à l’époque :
« Oneway can be used in conjunction with vehicle type in order to tag 
exceptions. I.e. oneway:moped=no for a one-way streets where mopeds are allowed 
to drive in the opposite direction. Bicycles (oneway:bicycle=no) are handled 
specially and  cycleway=opposite/opposite_lane/opposite_track needs to be added 
for compatibility: (See Key:access for sub-values or Bicycle for examples). »

Pour ma part, j’avais découvert la « nécessité » de cycleway=opposite car le 
rendu OCM n’affichait pas les double-sens cyclables qui n’avaient pas cet 
attribut.


Gwenaël

[1] 
https://wiki.openstreetmap.org/w/index.php?title=Key:oneway=1576104=1576102


Le 01/02/2019 à 13:47, Thomas Ruchin a écrit :
> Je pense que c'est du doublon d'information qui n'apporte pas grand chose et 
> qui est difficile à maintenir. Je ne sais pas quelle est la discussion qui a 
> conduit à cette rédaction du wiki.
> C'est comme si le wiki recommandait d'ajouter access=yes sur les routes qui 
> n'ont pas de restriction particulières d'accès.*
> Par contre, rechercher à mieux caractériser les voies sur lequel est présent 
> le oneway:bicycle=non sans plus de détail sur l'aménagement cyclable serait 
> intéressant.
> 
> Thomas

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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Thomas Ruchin]

Je pense que c'est du doublon d'information qui n'apporte pas grand chose
et qui est difficile à maintenir. Je ne sais pas quelle est la discussion
qui a conduit à cette rédaction du wiki.
C'est comme si le wiki recommandait d'ajouter access=yes sur les routes qui
n'ont pas de restriction particulières d'accès.*
Par contre, rechercher à mieux caractériser les voies sur lequel est
présent le oneway:bicycle=non sans plus de détail sur l'aménagement
cyclable serait intéressant.

Thomas

Le ven. 1 févr. 2019 à 13:00, Shohreh  a écrit :

> Bonjour,
>
> Le wiki en anglais* suggère qu'une rue en double-sens cyclable (DSC) soit
> indiquée par deux tags :
>
> "cycleway(:left|right)=opposite|opposite_lane|opposite_track"
> +
> "oneway:bicycle=no"
>
> Cependant, comme Id n'ajoute pas automatiquement ce second tuple
> "oneway:bicycle=no", il est fréquent que les DSC ne le possèdent pas… ce
> qui
> dissuade certains outils comme BRouter de faire passer les cyclistes par
> ces
> chemins et les oblige à faire un détour :
>
> https://postimg.cc/8JvbXbDp
> https://www.openstreetmap.org/way/24692380
>
> => Est-il acceptable par la communauté de faire une moulinette pour ajouter
> ce tuple manquant à tous les DSC déjà définis dans OSM avec
> "cycleway(:left|right)=opposite|opposite_lane|opposite_track" ?
>
> Merci.
>
> * https://wiki.openstreetmap.org/wiki/Bicycle
> Cas M3a et S1
>
>
>
> --
> 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

[OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Shohreh]

Bonjour,

Le wiki en anglais* suggère qu'une rue en double-sens cyclable (DSC) soit
indiquée par deux tags :

"cycleway(:left|right)=opposite|opposite_lane|opposite_track"
+
"oneway:bicycle=no"

Cependant, comme Id n'ajoute pas automatiquement ce second tuple
"oneway:bicycle=no", il est fréquent que les DSC ne le possèdent pas… ce qui
dissuade certains outils comme BRouter de faire passer les cyclistes par ces
chemins et les oblige à faire un détour :

https://postimg.cc/8JvbXbDp
https://www.openstreetmap.org/way/24692380

=> Est-il acceptable par la communauté de faire une moulinette pour ajouter
ce tuple manquant à tous les DSC déjà définis dans OSM avec
"cycleway(:left|right)=opposite|opposite_lane|opposite_track" ?

Merci.

* https://wiki.openstreetmap.org/wiki/Bicycle
Cas M3a et S1



--
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] Idées rendu des mers

[Frédéric Rodrigo]

L’idée des relations pour les mers est conceptuellement tentant.
Mais en pratique c'est pas si facile.

https://wiki.openstreetmap.org/wiki/Tag:place%3Dsea

Le wiki est déjà lui même en contradiction (relation ou pas relation ? )

"""
Please respect the limitation of members of a relation
"""
Contrainte assez difficile à respecter.

Les îles doivent-elle être dans la mer ou non, c'est à dire en "inner" ?

Il y déjà quelques relations:
http://overpass-turbo.eu/s/FII

Avec des approches différentes:
https://www.openstreetmap.org/relation/9051063#map=9/51.6521/1.2456
https://www.openstreetmap.org/relation/4497545#map=10/39.7473/20.0892

Avec Jocelyn on à déjà commencé à expérimenter les extracts de mers:
http://download.openstreetmap.fr/extracts/europe/seas/


My 3cents.
Frédéric.


Le 01/02/2019 à 10:09, Adrien Grellier a écrit :


Bonjour,

Merci pour vos réponses !!

Donc si j'ai bien compris, pour améliore le rendu il faudrait définir 
des relations pour les mers/baies/détroits/etc. avec en outer les 
côtes, en inner les îles. Ayant déjà travaillé sur les relations sur 
les marais de Loire Atlantique et les transports (vélo, rando, etc.), 
ça me semble jouable. La difficulté étant de trouver les délimitations 
précises.


Pour le rendu OSM-FR, je note que les natural=bay ne s'affiche pas 
encore dessus.


En passant le wiki me semble trompeur : les pages anglaises pour 
natural=bay ou place=sea indiquent de ne pas utiliser le tag sur des 
relations (symboles à droite)… mais le texte à gauche fait état de 
cette possibilité !



Merci à tous pour ces conseils. Je vais y aller très progressivement, 
donc si vous voyez des bêtises sur la carto des mers, n'hésitez pas 
mettre un message sur la liste ;-)


Bonne journée

Adrien

Le 31/01/2019 à 03:51, Jérôme Amagat a écrit :



Le mer. 30 janv. 2019 à 18:22, Adrien Grellier > a écrit :


Bonjour,

En ce moment je m'intéresse pas mal aux mers et océans, et
OpenStreetMap
me semble plutôt mauvais sur les rendus à faible zoom.

Voici par exemple 3 rendus différents de l'Atlantique Nord :

– OpenStreetMap : https://www.openstreetmap.org/#map=4/57.40/-17.58
– Rendu OSM-FR :

http://tile.openstreetmap.fr/?zoom=4=59.05751=-18.29251=BFF
– carte du SHOM :

https://data.shom.fr/#001=eyJjIjpbLTE4NTczMjMuMTUyMjg4MDcwNCw3NzE1Njc2LjEyNDE1OTkxNV0sInoiOjQsInIiOjAsImwiOlt7InR5cGUiOiJJTlRFUk5BTF9MQVlFUiIsImlkZW50aWZpZXIiOiJSQVNURVJfTUFSSU5FXzM4NTdfV01UUyIsIm9wYWNpdHkiOjEsInZpc2liaWxpdHkiOnRydWV9LHsidHlwZSI6IklOVEVSTkFMX0xBWUVSIiwiaWRlbnRpZmllciI6IkZEQ19HRUJDT19QWVItUE5HXzM4NTdfV01UUyIsIm9wYWNpdHkiOjEsInZpc2liaWxpdHkiOnRydWV9XX0=
(désolé pour le lien…)

La carte OpenStreetMap est totalement indigente : Aucune mers
n'apparaît, les principales îles n'ont plus (Féroé, Orcades,
Terre-Neuves, etc.), seuls les pays apparaissent, mais dans la
langue du
pays. Une petite exception : le golfe de Gascogne, qui apparaît
bizarrement sous deux noms. Impossible en l'état de se servir de ce
rendu comme planisphère !


pour ce rendu c'est le tag name qui est utiliser et doit etre en 
langue local donc pour le golf de Gascogne la langue des 2 pays 
limitrophes.
pour faire changer des chose sur ce rendu je crois que c'est ici 
qu'il faut demandé : 
https://github.com/gravitystorm/openstreetmap-carto/issues
le rendu assez souvent, on a vu apparaître les parc naturel régional 
il y a peu de temps.
j'ai pas regardé mais je pense que ça a déjà été demander d’améliorer 
le rendu des mer et je pense que le problème c'est que c'est 
difficile de connaître la taille d'un truc juste en ayant un node.

 Pour les île, je sais pas ?


Le rendu français est nettement mieux : les îles apparaissent
clairement, les noms sont traduits en français, mais les mers n'y
sont
pas. Bizarrement la situation s'inverse dans le nord du Canada :
OSM est
à mon sens nettement plus lisible que OSM-FR, les grosses îles
apparaissant de manière immédiate.


Là il faut demander à cquest c'est lui qui s'en occupe. Je crois que 
le rendu au faible zoom n'est calculé que très rarement et j'ai pas 
l'impression que des tag comme natural=bay (pour le golf de gascogne 
qui est comme ça dans osm depuis un moment il me semble contrairement 
à la manche et la mer d’Irlande qui sont assez nouvelles) soit géré 
par le rendu.
Il faut lui demander gentiment que la prochaine fois qu'il modifiera 
le rendu il fasse quelque chose pour ces tag :)



Enfin la carte du SHOM est nettement plus avancée, puisque tout
apparaît
clairement : détroit du Danemark, Mer Celtique, etc.


Comment faire pour améliorer le rendu des mers ? Est-ce un
problème de
données ? Par exemple la mer Celtique est présente dans OSM avec
un seul
point. Un multi-polygone serait-il plus adapté ? Ou bien est-ce un
problème du système de rendu dans les faibles zoom ?

J'aimerais bien pouvoir améliore la 

Re: [OSM-talk-fr] Idées rendu des mers

[Adrien Grellier]

Bonjour,

Merci pour vos réponses !!

Donc si j'ai bien compris, pour améliore le rendu il faudrait définir
des relations pour les mers/baies/détroits/etc. avec en outer les côtes,
en inner les îles. Ayant déjà travaillé sur les relations sur les marais
de Loire Atlantique et les transports (vélo, rando, etc.), ça me semble
jouable. La difficulté étant de trouver les délimitations précises.

Pour le rendu OSM-FR, je note que les natural=bay ne s'affiche pas
encore dessus.

En passant le wiki me semble trompeur : les pages anglaises pour
natural=bay ou place=sea indiquent de ne pas utiliser le tag sur des
relations (symboles à droite)… mais le texte à gauche fait état de cette
possibilité !


Merci à tous pour ces conseils. Je vais y aller très progressivement,
donc si vous voyez des bêtises sur la carto des mers, n'hésitez pas
mettre un message sur la liste ;-)

Bonne journée

Adrien

Le 31/01/2019 à 03:51, Jérôme Amagat a écrit :
>
>
> Le mer. 30 janv. 2019 à 18:22, Adrien Grellier  > a écrit :
>
> Bonjour,
>
> En ce moment je m'intéresse pas mal aux mers et océans, et
> OpenStreetMap
> me semble plutôt mauvais sur les rendus à faible zoom.
>
> Voici par exemple 3 rendus différents de l'Atlantique Nord :
>
> – OpenStreetMap : https://www.openstreetmap.org/#map=4/57.40/-17.58
> – Rendu OSM-FR :
> 
> http://tile.openstreetmap.fr/?zoom=4=59.05751=-18.29251=BFF
> – carte du SHOM :
> 
> https://data.shom.fr/#001=eyJjIjpbLTE4NTczMjMuMTUyMjg4MDcwNCw3NzE1Njc2LjEyNDE1OTkxNV0sInoiOjQsInIiOjAsImwiOlt7InR5cGUiOiJJTlRFUk5BTF9MQVlFUiIsImlkZW50aWZpZXIiOiJSQVNURVJfTUFSSU5FXzM4NTdfV01UUyIsIm9wYWNpdHkiOjEsInZpc2liaWxpdHkiOnRydWV9LHsidHlwZSI6IklOVEVSTkFMX0xBWUVSIiwiaWRlbnRpZmllciI6IkZEQ19HRUJDT19QWVItUE5HXzM4NTdfV01UUyIsIm9wYWNpdHkiOjEsInZpc2liaWxpdHkiOnRydWV9XX0=
> (désolé pour le lien…)
>
> La carte OpenStreetMap est totalement indigente : Aucune mers
> n'apparaît, les principales îles n'ont plus (Féroé, Orcades,
> Terre-Neuves, etc.), seuls les pays apparaissent, mais dans la
> langue du
> pays. Une petite exception : le golfe de Gascogne, qui apparaît
> bizarrement sous deux noms. Impossible en l'état de se servir de ce
> rendu comme planisphère !
>
>
> pour ce rendu c'est le tag name qui est utiliser et doit etre en
> langue local donc pour le golf de Gascogne la langue des 2 pays
> limitrophes.
> pour faire changer des chose sur ce rendu je crois que c'est ici qu'il
> faut demandé : https://github.com/gravitystorm/openstreetmap-carto/issues
> le rendu assez souvent, on a vu apparaître les parc naturel régional
> il y a peu de temps.
> j'ai pas regardé mais je pense que ça a déjà été demander d’améliorer
> le rendu des mer et je pense que le problème c'est que c'est difficile
> de connaître la taille d'un truc juste en ayant un node.
>  Pour les île, je sais pas ?
>
>
> Le rendu français est nettement mieux : les îles apparaissent
> clairement, les noms sont traduits en français, mais les mers n'y sont
> pas. Bizarrement la situation s'inverse dans le nord du Canada :
> OSM est
> à mon sens nettement plus lisible que OSM-FR, les grosses îles
> apparaissant de manière immédiate.
>
>
> Là il faut demander à cquest c'est lui qui s'en occupe. Je crois que
> le rendu au faible zoom n'est calculé que très rarement et j'ai pas
> l'impression que des tag comme natural=bay (pour le golf de gascogne
> qui est comme ça dans osm depuis un moment il me semble contrairement
> à la manche et la mer d’Irlande qui sont assez nouvelles) soit géré
> par le rendu.
> Il faut lui demander gentiment que la prochaine fois qu'il modifiera
> le rendu il fasse quelque chose pour ces tag :)
>
>
> Enfin la carte du SHOM est nettement plus avancée, puisque tout
> apparaît
> clairement : détroit du Danemark, Mer Celtique, etc.
>
>
> Comment faire pour améliorer le rendu des mers ? Est-ce un problème de
> données ? Par exemple la mer Celtique est présente dans OSM avec
> un seul
> point. Un multi-polygone serait-il plus adapté ? Ou bien est-ce un
> problème du système de rendu dans les faibles zoom ?
>
> J'aimerais bien pouvoir améliore la situation, mais je ne sais pas
> vraiment quoi faire… si vous avez des suggestions ça m'intéresse !!
>
>
> Pour les océans peut être pas mais pour des mers pas trop grande il
> faudrait qu'elles soit présentent sous forme de surface. elles
> pourrait apparaître sur le rendu international comme le golfe de
> Gascogne ou la mer d’Irlande et peut être dans d'autres rendu dans
> quelques temps.
> le golf de Gascogne https://www.openstreetmap.org/relation/7156290
> c'est un grand multipolygon (2285 membres !) avec comme tag natural=bay.
> la manche https://www.openstreetmap.org/relation/9280887 c'est un
> chemin pas très précis (je viens de le changer en multipolygon avec
> comme inner les îles anglo normande pour essayé de faire remonter un
> peu