Re: [OSM-talk-fr] Rendu FR... un peu de neuf

2016-09-03 Par sujet Philippe Verdy 
Le 3 septembre 2016 à 22:38, Christian Quest  a
écrit :

> Les nouveautés du samedi...
>
> - bug corrigé sur les ponts, et j'en ai profité pour ajouter le rendu des
> man_made=bridge ce qui permet de voir l'emprise des ponts, exemple:
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#1
> 8/48.85716/2.34108
>
> - l'ordre de priorité pour placer les noms dans les petites échelles (zoom
> 6 par exemple) est revu, et Vannes est bien au rendez-vous:
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/46.958/2.615
>

Arf! "Plérin" visible à la place de "Saint-Brieuc" (pourtant chef-lieu de
département et nettement plus peuplé).

Même chose pour :
- Cherbourg-en-Contentin (on voit Digosville),
- Saint-Malo (on voit le Petit Bé, une petite île devant Saint-Malo, dans
population quelques rochers et de la lande, et au moins une cinquantaine de
fois plus petit que la commune ou 15 fois celle des quartiers d'Intra-Muros
ou Paramé),
- Le Havre et Caen (on voit Villainville)
- Landerneau (on voit le village de Loudiry)
- Île-deBréhat (on voit Barafot)
- Avignon (on voit Alès)
- Limoges (on voir Roumazières)
- Metz (on voit Jamy)
- Thionville (on voit Longuyon)

ces plus petits villages ou ilets disparaissent au niveau 7 pour afciher
les plus grosses communes (non affichées au niveau 6), et ne reviennent
qu'à des niveaux plus élevés

Et toujours les arrondissements de Paris au niveau admin 9 dont on a du mal
à voir les limites (qui devraient commencer à être visible vers le niveau
13 qui affiche la capitale sur presque tout l'écran en Full HD).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

2016-09-03 Par sujet Christian Quest 
 Les nouveautés du samedi...

- bug corrigé sur les ponts, et j'en ai profité pour ajouter le rendu des
man_made=bridge ce qui permet de voir l'emprise des ponts, exemple:
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
18/48.85716/2.34108

- l'ordre de priorité pour placer les noms dans les petites échelles (zoom
6 par exemple) est revu, et Vannes est bien au rendez-vous:
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/46.958/2.615

- des icônes de commerces avaient disparu, elles sont de retour (contrôle
technique, lavage auto, glaces, etc)

- icône pour les bornes de recharge de véhicules électriques:
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.85187/3.54325

ainsi que plein de petites bricoles...

Pour les côtes, je vais voir ce que je peux faire, en fait les limites
administratives n'ont pas besoin d'être mises sur les côtes, mais encore
faut-il pouvoir faire le tri ;)

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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

2016-09-03 Par sujet osm . sanspourriel 

Rassures-toi, on voit que tu es plus "pas convaincu" qu'agressif.

Pour que les moteurs puissent t'indiquer le chemin il faut qu'ils aient 
l'information. Si tu cherches le 23 rue Tartempion, si l'adresse n'est 
pas dans la base ça devient plus difficile.


> pourquoi indiquer la rue sur un bâtiment puisqu’il ne s’agit que d’un 
objet aussi ?!


Je suis d'accord avec toi, il faut indiquer la rue sur la rue, le numéro 
du bâtiment sur le bâtiment et regrouper les numéros et la rue dans une 
associatedStreet.


Et comme ça on n'a pas de mystère pour associer le bâtiment à la bonne rue.

Tu dis que pour accéder à la Boîte aux lettres, Rue des Baumelles, 
Toulon il faut y accéder par une autre rue.


1) j'en doute, tu veux dire *en voiture* car des bàl placées dans une 
rue mais non accessibles par la rue, même à pied, ça va fortement 
limiter l'intérêt de la bàl ;-).


J'entends bien que c'est un exemple virtuel mais ma réponse montre que 
l'accessibilité est un mauvais critère pour donner une adresse (mais une 
information pertinente : si le trottoir n'est pas accessible aux 
fauteuils roulants, le moteur orienté handicap moteur doit favoriser 
d'autres bàl proches).


2) je vois une curiosité sur cette rue de Baumelles, elle est en trois 
morceaux (joints) mais Nominatim n'en montre qu'un.


Est-ce parce que les morceaux sont contigus ? Alors il vaudrait mieux 
retourner tous les morceaux liés d'un coup comme une relation.


Sur un autre exemple assez similaire, La rue de Brigadier Le Cann à 
Brest, elle aussi avec des appendices, Nominatim propose 2 tronçonx de 
la partie principale (sur 4).



Le 03/09/2016 à 11:02, Axelos - axe...@broman.fr a écrit :

cquest wrote

C'est le boulot d'un calculateur d'itinéraire de gérer ça, plutôt que
d'indiquer l'accès dans les attributs de l'objet.

Mouai, je n’arrive pas trop à saisir cette logique. Après tout finalement,
pourquoi indiquer la rue sur un bâtiment puisqu’il ne s’agit que d’un objet
aussi ?!

Et si le bâtiment est lui aussi plus proche d’une autre Rue que celle qu’il
est normalement lié, pas bien grave, le calculateur devra le savoir (comment
par contre mystère) !


cquest wrote

On retombe ici sur une question : équilibre entre base de données
relationnelles et base de données géographiques... OSM est avant tout une
base de données géographiques.

Je ne suis pas expert en la matière, mais visiblement la base de données
géographiques comprend aussi les adresses, donc je vois pas le problème ?

PS : En me relisant, je pense que mon message peut paraître un peu agressif,
mais ce n'est pas le cas :)


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

Re: [OSM-talk-fr] Contribution à OpenStreetMap sur Android

2016-09-03 Par sujet Vincent Pottier 

Le 22/08/2016 à 17:33, loic ortola a écrit :

Bonjour à tous,

Bonjour,

Merci infiniment pour ceux qui auront la patience de s'y intéresser,
n'hésitez pas à répondre à ce mail pour avoir votre accès à la beta.

Loïc

Partant aussi sur Fairphone 1U.
Mais je ne suis plus un bourreau de travail sur OSM...

D'accord avec les remarques de Charles sur la mutualisation des données 
avec OSMAnd.


FrViPofm

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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

2016-09-03 Par sujet Christian Quest 

Le 03/09/2016 à 11:02, Axelos a écrit :

cquest wrote

C'est le boulot d'un calculateur d'itinéraire de gérer ça, plutôt que
d'indiquer l'accès dans les attributs de l'objet.

Mouai, je n’arrive pas trop à saisir cette logique. Après tout finalement,
pourquoi indiquer la rue sur un bâtiment puisqu’il ne s’agit que d’un objet
aussi ?!


Je n'indique pas la rue sur un bâtiment non plus... mais là on va 
rentrer dans le débat de comment modéliser les adresses.


Un bâtiment n'est pas une adresse... une adresse n'est pas qu'un 
bâtiment, un adresse c'est un point de repère. Tout ce qui se trouve à 
proximité de ce point de repère se lie... par proximité, mais il ne faut 
pas confondre l'un et l'autre.



Et si le bâtiment est lui aussi plus proche d’une autre Rue que celle qu’il
est normalement lié, pas bien grave, le calculateur devra le savoir (comment
par contre mystère) !


Par la géométrie. Quand on calcule un itinéraire on part d'une 
coordonnée géographique (parce qu'on part d'un endroit physique), on 
cherche le highway=* le plus proche et on calcule l'itinéraire à partir 
de là. si ce n'est pas le bon highway qui est choisit... c'est qu'il en 
manque qui devrait arriver plus proche de notre point de départ (comme 
un chemin d'accès privé au bâtiment).





cquest wrote

On retombe ici sur une question : équilibre entre base de données
relationnelles et base de données géographiques... OSM est avant tout une
base de données géographiques.

Je ne suis pas expert en la matière, mais visiblement la base de données
géographiques comprend aussi les adresses, donc je vois pas le problème ?


Oui, mais les adresses sont des objets en tant que tels, pas une 
information à répéter (inutilement) sur tout et n'importe quoi.


Le candélabre devant chez moi n'a pas d'adresse, mais l'adresse la plus 
proche on l'obtient facilement par un croisement géométrique.



PS : En me relisant, je pense que mon message peut paraître un peu agressif,
mais ce n'est pas le cas :)




Pareil ;)

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

2016-09-03 Par sujet Axelos 
cquest wrote
> C'est le boulot d'un calculateur d'itinéraire de gérer ça, plutôt que
> d'indiquer l'accès dans les attributs de l'objet.

Mouai, je n’arrive pas trop à saisir cette logique. Après tout finalement,
pourquoi indiquer la rue sur un bâtiment puisqu’il ne s’agit que d’un objet
aussi ?!

Et si le bâtiment est lui aussi plus proche d’une autre Rue que celle qu’il
est normalement lié, pas bien grave, le calculateur devra le savoir (comment
par contre mystère) !


cquest wrote
> On retombe ici sur une question : équilibre entre base de données
> relationnelles et base de données géographiques... OSM est avant tout une
> base de données géographiques.

Je ne suis pas expert en la matière, mais visiblement la base de données
géographiques comprend aussi les adresses, donc je vois pas le problème ?

PS : En me relisant, je pense que mon message peut paraître un peu agressif,
mais ce n'est pas le cas :)



--
View this message in context: 
http://gis.19327.n5.nabble.com/Bonnes-et-moins-bonnes-visibilites-OSM-tp5875216p5881630.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

2016-09-03 Par sujet Philippe Verdy 
Le 3 septembre 2016 à 10:03,  a écrit :

> - golfe du Morbihan (côte + RN http://www.openstreetmap.org/r
> elation/1255492).
>
À ce niveau de rendu les contours me semblent trop marqués pour des formes
> complexes.
>

On a tenu compte dans le golfe du Mobihan des zones exclues des limites
communales car faisant partie du domaine maritime national, cependant on a
aussi les limites des zones protégées du parc naturel.

En revanche tu noteras qu'il y a une différence entre les limites
communales et la limite régionale qui inclut totalement le Golfe du
Morbihan, par un trait coupant la passe (et qui n'est pas la ligne de côte.

Normalement on aurait du faire le même détail dans le Ria d'Etel (les
limites communales sont trop arbitraires, sans doute issues du cadastre qui
est tout aussi grossier et arbitraire). Ca demande à être plus détaillé car
les communes sont trop étendues sur le domaine maritime, même si le ria est
entièrement inclus dans les limites régionales (le département n'a pas de
compétence sur ce domaine naturel contrairement à la région, le département
devrait suivre les limites communales (comme aussi les EPCI, et même les
arrondissements départementaux qui n'ont aucune compétence autre que celles
de l'Etat dans son administration préfectorale).

Je ne vois aucune anomalie flagrante dans le Golfe du Morbihan (je ne
trouve pas du tout le rendu "trop complexe", il traduit assez bien ce
découpage complexe).

Le 3 septembre 2016 à 10:03,  a écrit :

> Je complète par un exemple plus flagrant :
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 11/47.6302/-3.0590 
>
> http://www.openstreetmap.org/#map=11/47.6300/-3.0590
>
> Et oui, les côtes bretonnes étant échancrées, augmenter le trait de côte
> ou les zones protégées rend la carte assez confuse.
>
> En fait je disais trait de côte mail il s'agit des limites administratives.
> Ici on voit 4 rendus très différents pour des zones assez similaires (de
> l'ouest à l'est) :
> - Rade de Lorient, côte + limite administrative
> - Ria d'Etel (je suis obligé de décrire, manque sans doute le nom sur la
> Ria et Magouër empêche l'affichage de la commune d'Etel : Magouër, St
> Hélène Nostang, Locoal-Mendon, Belz), natural=water mais soumise à la marée.
> - golfe du Morbihan (côte + RN http://www.openstreetmap.org/
> relation/1255492).
> À ce niveau de rendu les contours me semblent trop marqués pour des formes
> complexes.
>
> Soit à ce niveau on fait des traits plus légers, soit partout soit pour
> les intérieurs des polygones.
> Soit encore on tient compte du rapport surface/périmètre pour déterminer
> le style (largeur, couleur, dégradé).
>
> Ici les différences de rendu sont impressionnantes :
> http://www.openstreetmap.org/#map=12/47.5938/-2.7761
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 12/47.5939/-2.7765
> À mon avis, c'est bien de rendre le nom des îlots (pourquoi l'
> Île-aux-Moines  n'apparaît pas
> ? Doit on comme pour le caillou Île du Charles
>  ajouter un place=island, ça
> me semble logique, je le fait de ce pas), avec les traits à l'ancienne
> sinon c'est trop chargé.
>
> Et si l'expression publicitaire, Bretagne terre de contraste" venait des
> travaux cartographiques de Christian ?
>
>
> Le 02/09/2016 à 22:28, osm.sanspourr...@spamgourmet.com a écrit :
>
> * C'est plus du détail mais les polders se distinguent moins bien de la
> mer :
>
> http://www.openstreetmap.org/#map=13/48.3901/-4.4734
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 13/48.3901/-4.4734
>
> * Au niveau 11, le trait de côte est très visible et le trait des rives
> des fleuves absent alors qu'au niveau 12 c'est plus propre :
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 11/48.3901/-4.4734
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 12/48.3613/-4.5499
>
> 
>
> Comme cette limite n'est pas la limite des marée mais un trait arbitraire
> dans les estuaires, ça fait drôle en Bretagne (1/3 des fleuves bretons sont
> maritimes, ci l'Elorn de Landerneau au pont de Plougastel).
>
> Soit limiter l'épaisseur en niveau 11 soit ajouter le tracé des rives des
> fleuves .
>
> Le 02/09/2016 à 21:48, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Vu, ainsi que http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 13/48.8575/2.3462
>
> Le 2 septembre 2016 à 20:02, Marc Sibert  a écrit :
>
>> Bonjour à tous,
>>
>> Un bug sur les ponts ?
>>
>> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#1
>> 3/48.7317/2.3672
>>
>> ce qui particulièrement criant sur le point de l'orly val à Orly.
>>
>> A+
>>
>> Marc Sibert
>> mailto:m...@sibert.fr
>>
>> Le 01/09/2016 à 09:14, Christian

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

2016-09-03 Par sujet Philippe Verdy 
Le 3 septembre 2016 à 10:03,  a écrit :

> - golfe du Morbihan (côte + RN http://www.openstreetmap.org/
> relation/1255492).
>
À ce niveau de rendu les contours me semblent trop marqués pour des formes
> complexes.
>

On a tenu compte dans le golfe du Mobihan des zones exclues des limites
communales car faisant partie du domaine maritime national, cependant on a
aussi les limites des zones protégées du parc naturel.

En revanche tu noteras qu'il y a une différence entre les limites
communales et la limite régionale qui inclut totalement le Golfe du
Morbihan, par un trait coupant la passe (et qui n'est pas la ligne de côte.

Normalement on aurait du faire le même détail dans le Ria d'Etel (les
limites communales sont trop arbitraires, sans doute issues du cadastre qui
est tout aussi grossier et arbitraire). Ca demande à être plus détaillé car
les communes sont trop étendues sur le domaine maritime, même si le ria est
entièrement inclus dans les limites régionales (le département n'a pas de
compétence sur ce domaine naturel contrairement à la région, le département
devrait suivre les limites communales (comme aussi les EPCI, et même les
arrondissements départementaux qui n'ont aucune compétence autre que celles
de l'Etat dans son administration préfectorale).

Je ne vois aucune anomalie flagrante dans le Golfe du Morbihan (je ne
trouve pas du tout le rendu "trop complexe", il traduit assez bien ce
découpage complexe).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

2016-09-03 Par sujet Philippe Verdy 
Note: une exception à cette "règle" a été faite dans l'estuaire de la Rance
(pourtant fermé par un barrage avec même une importante route permanente
dessus entre Dinard et Saint-Malo (qui cependant possède une petite section
levante au niveau de l'écluse): l'esturaire est tellement large que les
lignes administratives remontent très loin;

L'estuaire fait aussi l'objet d'une protection et d'une surveillance de
l'écosystème marin. la "ligne de côte" d'OSM remonte donc au delà du
barrage de la Rance jusqu'au port de Dinan. en amont du port, il y a encore
des zones inondables mais elles restent souvent découvertes même à marée
haute et sont de vrais marais avec des herbes hautes (ce ne sont pas des
"polders" non plus) avec son chenal naturel étroit mais permanent, maintenu
en eaux par l'écluse du port, et avec des eaux essentiellement fluviales
même si de l'eau de mer vient s'y mêler à marée haute quand l'écluse du
port de Dinan est ouverte avec une salinité relativement faible du fait de
la faible proportion d'eau de mer et du flux d'eau douce appporté par la
Rance.

Concernant les abers au sud de la rade de Brest, on peut se poser la
question s'il faut utiliser le pont ou remonter plus haut la frontière
administrative sur la partie maritime du fleuve (d'autant que la loi
Littoral concerne des communes plus en amont), comme on l'a fait sur la
Rance. La question se pose aussi dans des zones de marais côtiers avec une
passe marine étroite le long du sud de la Bretagne.

La question se pose aussi pour le Golfe du Morbihan: coupé par la frontière
administrative régionale (car c'est un parc naturel régional) mais les
communes, elles, ont leur frontière excluant les zones marines du golfe (et
d'ailleurs nombre des iles émergées sont dans le domaine maritime). Mais la
limite régionale coupe arbitrairement l'entrée du golfe (sans être taguée
elle-même comme "ligne de côte": les lignes de côte font bien le tour du
golfe et délimitent chacune des îles)

On peut aussi analyser et discuter les côtes du golfe du Roussilon.

Tout cela n'est pas un problème de rendu, mais il s'agit juste de rendre
compte assez fidèlement les réalités de terrain:

* il est difficile d'établir les limites communales (car le cadastre n'aide
pas du tout, le littoral étant de toute façon non compétent puisqu'il n'y a
normalement pas de "propriété" privée et que le littoral est un domaine
public national, où les communes ont cependant une compétence limitée aux
installations portuaires et à l'accessibilité, la sécurité et la salubrité
des plages et ne peuvent pas délivrer de permis de construire sans aval de
l'Etat (avec recours possible devant les tribunaux administratifs et le
conseil d'Etat: les assos de riverains et de protection d'environnement et
les agences portuaires font souvent des recours, mais le préfet local
représentant l'Etat y fait appel assez souvent pour obtenir des expulsions
et la destruction d'installations privées et annuler des décisions
municipales accordant des autorisations sur les plages).
* les limites régionales sont un peu plus faciles et incluent généralement
aussi les parcs régionaux, et tous les ponts et barrages et routes
nationales et départementales qui les traversent.
* entre les deux c'est une estimation de ce qu'on appelle les "eaux
intérieures".

Le SHOM a founit des données un peu plus détaillées mais d'un point de vue
environnemental. Son tracé ne tient pas compte des réalités administratives
locales et du fait qu'on a choisit dans OSM d'inclure les zones portuaires
et zones d'ancrage dans les estuaires dans les limites communales (ce qui
traduit bien les nombreuses arrêts en conseil d'Etat ou en cassation qui
vont dans le même sens, soit pour protéger le littoral contre les riverains
et collectivités locales, soit pour établir la responsabilité limitée des
communes).

Dans OSM on distingue donc clairement ce qui est les frontières
administratives et les frontières naturelles. mais hors des estuaires et
ports, on a choisi de les confondre et cela donne aussi une carte plus
réaliste et moins "fouillie", plus facile à traiter (il reste le cas
particulier des plages souvent tracées entièrement côté mer (la ligne de
côte exclut totalement la plage au lieu de la couper sur la laisse de mer,
ce trait de côte étant alors à réutiliser quand même comme ligne
administrative).

Le 3 septembre 2016 à 10:01, Philippe Verdy  a écrit :

> Ce n'est pas le trait de côte en tant que tel qu'on voit, c'est la ligne
> administratitive (qui il est vrai est un peu arbitraire au travers des
> estuaires, mais suit généralement la coupure au dernier pont, barrage (ou
> barrière de sel), même si la mer peut remonter plus loin et l'effet des
> marées peut encore se faire sentir notamment dans les abers bretons
> Ce qui donne de larges zones découvertes à marée basse, où les bateaux
> dans l'estuaire sont posés sur le fond, mélange de sable marin, de vase,
> d'alluvions fluvieux, d'algues et habitat de nombreux

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

2016-09-03 Par sujet osm . sanspourriel 

Je complète par un exemple plus flagrant :

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/47.6302/-3.0590 



http://www.openstreetmap.org/#map=11/47.6300/-3.0590

Et oui, les côtes bretonnes étant échancrées, augmenter le trait de côte 
ou les zones protégées rend la carte assez confuse.


En fait je disais trait de côte mail il s'agit des limites administratives.

Ici on voit 4 rendus très différents pour des zones assez similaires (de 
l'ouest à l'est) :

- Rade de Lorient, côte + limite administrative
- Ria d'Etel (je suis obligé de décrire, manque sans doute le nom sur la 
Ria et Magouër empêche l'affichage de la commune d'Etel : Magouër, St 
Hélène Nostang, Locoal-Mendon, Belz), natural=water mais soumise à la marée.
- golfe du Morbihan (côte + RN 
http://www.openstreetmap.org/relation/1255492).
À ce niveau de rendu les contours me semblent trop marqués pour des 
formes complexes.


Soit à ce niveau on fait des traits plus légers, soit partout soit pour 
les intérieurs des polygones.
Soit encore on tient compte du rapport surface/périmètre pour déterminer 
le style (largeur, couleur, dégradé).


Ici les différences de rendu sont impressionnantes :
http://www.openstreetmap.org/#map=12/47.5938/-2.7761
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#12/47.5939/-2.7765
À mon avis, c'est bien de rendre le nom des îlots (pourquoi 
l'Île-aux-Moines  n'apparaît 
pas ? Doit on comme pour le caillou Île du Charles 
 ajouter un place=island, ça 
me semble logique, je le fait de ce pas), avec les traits à l'ancienne 
sinon c'est trop chargé.


Et si l'expression publicitaire, Bretagne terre de contraste" venait des 
travaux cartographiques de Christian ?


Le 02/09/2016 à 22:28, osm.sanspourr...@spamgourmet.com a écrit :


* C'est plus du détail mais les polders se distinguent moins bien de 
la mer :


http://www.openstreetmap.org/#map=13/48.3901/-4.4734

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.3901/-4.4734

* Au niveau 11, le trait de côte est très visible et le trait des 
rives des fleuves absent alors qu'au niveau 12 c'est plus propre :


http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#11/48.3901/-4.4734

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#12/48.3613/-4.5499


Comme cette limite n'est pas la limite des marée mais un trait 
arbitraire dans les estuaires, ça fait drôle en Bretagne (1/3 des 
fleuves bretons sont maritimes, ci l'Elorn de Landerneau au pont de 
Plougastel).


Soit limiter l'épaisseur en niveau 11 soit ajouter le tracé des rives 
des fleuves .



Le 02/09/2016 à 21:48, Christian Quest - cqu...@openstreetmap.fr a écrit :
Vu, ainsi que 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.8575/2.3462


Le 2 septembre 2016 à 20:02, Marc Sibert > a écrit :


Bonjour à tous,

Un bug sur les ponts ?

http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#13/48.7317/2.3672



ce qui particulièrement criant sur le point de l'orly val à Orly.

A+

Marc Sibert
mailto:m...@sibert.fr 

Le 01/09/2016 à 09:14, Christian Quest a écrit :

Pas mal de petites modifications sur le rendu FR sont en test.

Vous pouvez voir où j'en suis sur
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740


Quoi de neuf ?

- de nouvelles icônes pour les commerces

- des labels de taille et de couleur variant avec la taille
du polygone qu'ils décrivent (texte en vert pour une forêt,
plus gros si la forêt est grande, etc)

- amélioration des frontières... les pointillés ne devraient
plus se mélanger comme avant, les noms ne devraient plus être
coupés en bord de metatile

- harmonisation des largeurs de routes et réorganisation du
tracé des layers 1-5


Au delà de ces modifications visibles, il y a pas mal de
nettoyage des fichiers de la feuille de style pour faciliter
sa mise à jour. Quelques améliorations aussi sur les requêtes
SQL (une bonne dizaine de requêtes de moins par exemple sur
le tracé des 5 niveaux de layer).

Bref, beaucoup de changements (le détail est sur
https://github.com/cquest/osmfr-cartocss/commits/master
)
qui ont pu casser ici ou là des choses que je n'ai pas pu
voir, donc si il y a des anomalies merci de les signaler avec
l'URL sur cette carte umap (qui contient le zoom et les
coordonnées).

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

2016-09-03 Par sujet Philippe Verdy 
Ce n'est pas le trait de côte en tant que tel qu'on voit, c'est la ligne
administratitive (qui il est vrai est un peu arbitraire au travers des
estuaires, mais suit généralement la coupure au dernier pont, barrage (ou
barrière de sel), même si la mer peut remonter plus loin et l'effet des
marées peut encore se faire sentir notamment dans les abers bretons
Ce qui donne de larges zones découvertes à marée basse, où les bateaux dans
l'estuaire sont posés sur le fond, mélange de sable marin, de vase,
d'alluvions fluvieux, d'algues et habitat de nombreux crustacés et refuge
et garde-manger pour de nombreux oiseaux marins qui viennent y picorer; ces
zones sont parfois poldérisées mais pas toujours (ne fait rarement) sauf
pour aménager un port accessible par un chenal entretenu et des quais ou
zones de services, dans des zones protégées par des digues (et parfois
maintenues avec un niveau d'eau suffisant par des écluses marines ou par
des portes qu'on relève quand la mer baisse.

Comme ce sont aussi des zones portuaires ou d'ancrage (surtout maintenant
pour les voiliers de loisir, mais aussi des bateaux de pêche côtière ou de
caséieurs à fond plat ou à quille relevable), il est normal de les inclure
dans les limites administratives.

Le chenal résiduel à marée basse dans les abers est trop étroit (souvent
moins de 50 mètres) pour en faire une vraie ligne de côte, mais à marée
haute l'aber est très large et la ligne de côte entre dans les terres et
suit à peu près les recommandations pour OSM. Normalement on devrait tracer
encore dans ces abers une zone de "terres humides" représentant les zones
découvertes à marée basse (fonds sableux ou vaseux, ou roches plus ou moins
colonisées par les coquillages, crustacés et algues et où persiste de
nombreuses flaques). Ces zones humides se porusivent hors de la zone
intérieure de la limite administrative un peu arbitraire coupant
l'estuaire. Dans OSM on peut aussi taguer simplement les zones soumises à
marée ("tidal") mais le rendu OSM par défaut ne les affiche pas (au
contraire des "terres humides" quand elles s'étendent aussi côté "mer" au
delà de la ligne de côte "coastline" d'OSM tracée à hautes eaux plus ou
moins le long de la laisse de mer ou le long des digues et des derniers
ponts et barrages)

Cette frontière visible n'est pas la frontière internationale (placée à 12
miles environ) mais régionale/départementale/communale, on la voit donc
comme régionale. Je ne vois pas où est donc l'anomalie.

Le 2 septembre 2016 à 22:28,  a écrit :

> * C'est plus du détail mais les polders se distinguent moins bien de la
> mer :
>
> http://www.openstreetmap.org/#map=13/48.3901/-4.4734
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 13/48.3901/-4.4734
>
> * Au niveau 11, le trait de côte est très visible et le trait des rives
> des fleuves absent alors qu'au niveau 12 c'est plus propre :
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 11/48.3901/-4.4734
>
> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 12/48.3613/-4.5499
>
> 
>
> Comme cette limite n'est pas la limite des marée mais un trait arbitraire
> dans les estuaires, ça fait drôle en Bretagne (1/3 des fleuves bretons sont
> maritimes, ci l'Elorn de Landerneau au pont de Plougastel).
>
> Soit limiter l'épaisseur en niveau 11 soit ajouter le tracé des rives des
> fleuves .
>
> Le 02/09/2016 à 21:48, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Vu, ainsi que http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#
> 13/48.8575/2.3462
>
> Le 2 septembre 2016 à 20:02, Marc Sibert  a écrit :
>
>> Bonjour à tous,
>>
>> Un bug sur les ponts ?
>>
>> http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#1
>> 3/48.7317/2.3672
>>
>> ce qui particulièrement criant sur le point de l'orly val à Orly.
>>
>> A+
>>
>> Marc Sibert
>> mailto:m...@sibert.fr
>>
>> Le 01/09/2016 à 09:14, Christian Quest a écrit :
>>
>>> Pas mal de petites modifications sur le rendu FR sont en test.
>>>
>>> Vous pouvez voir où j'en suis sur http://umap.openstreetmap.fr/f
>>> r/map/test-rendu-osmfr_99740
>>>
>>> Quoi de neuf ?
>>>
>>> - de nouvelles icônes pour les commerces
>>>
>>> - des labels de taille et de couleur variant avec la taille du polygone
>>> qu'ils décrivent (texte en vert pour une forêt, plus gros si la forêt est
>>> grande, etc)
>>>
>>> - amélioration des frontières... les pointillés ne devraient plus se
>>> mélanger comme avant, les noms ne devraient plus être coupés en bord de
>>> metatile
>>>
>>> - harmonisation des largeurs de routes et réorganisation du tracé des
>>> layers 1-5
>>>
>>>
>>> Au delà de ces modifications visibles, il y a pas mal de nettoyage des
>>> fichiers de la feuille de style pour faciliter sa mise à jour. Quelques
>>> améliorations aussi sur les requêtes SQL (une bonne dizaine de requêtes de
>>> moins par exemple sur le tracé