Re: [OSM-talk-fr] Présence sur le salon Primevère (Lyon) - 24/26 fév

[Yves Rouquier]

Bonjour ,

L’association La Ville à Vélo présentera la carte des aménagements cyclables de
la région lyonnaise réalisée avec OSM . ( http://carte.lavilleavelo.org/ ).

Je suis aussi membre de l'ALDIL , Je prépare une version portable ( cle usb )
de notre carte pour la mettre à disposition sur le stand de l'ALDIL.




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

Re: [OSM-talk-fr] J'aime les logiciels Libres, J'aime les données Libres, J'aime, J'aime ...

[Emilie Laffray]

Euh appeler un virus de l'amour AIDS est d'un mauvais goût le plus complet
vu que c'est l'acronyme du SIDA en anglais.

Emilie Laffray
On Feb 14, 2012 4:17 AM, "Philippe Verdy"  wrote:

> Le 13 février 2012 23:47, Pieren  a écrit :
> > 2012/2/13 Pierre Béland :
> >> Nous avons eu l'idée de propager aujourd'hui un Virus d'amour!
> >>
> >
> > Y en a qui n'ont pas fumé que la moquette, là :)
>
> Et ce Virus d'amour, qu'on appellera « Haute Intelligence des
> Volontaires », donnera-t-il des "AIDS" à notre petite Communauté ?
> Laissera-t-il des traces incurables chez nos Corps constitués, qui
> croient protéger leurs SIG dans le secret du non-dit ? Et s'ils
> trouvaient des thérapies multiples contre cette contamination qui n'a
> rien d'accidentel ? Et doit-on s'attendre ensuite au dénigrement et à
> la discrimination des données ? Il est temps de promouvoir des tests
> libres et gratuits, et se battre contre les brevets qui envahissent et
> polluent nos libertés.
> Let's act up, now !
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] J'aime les logiciels Libres, J'aime les données Libres, J'aime, J'aime ...

[Cyrille Giquello]

C'est rigolo, j'aime.

Heu, il n'y a pas beaucoup de français qui ont témoignés ...

Le 13 février 2012 17:55, Pierre Béland  a écrit :
>
>
> Un virus d'amour se propage sur internet aujourd'hui
>
> Heather Leson et moi étions à une conférence à Ottawa la semaine dernière.
> Nous discutions de groupes humanitaires, de cartographie de crise, et de
> données Libres (ie.Open Data et Open Source). Nous avons eu l'idée
> de propager aujourd'hui un Virus d'amour!
>
> Laissons savoir à tous que nous aimons les données et logiciels
> Libres. Propageons le virus d'amour sur internet aujourd'hui. SVP,
> joignez-vous à nous et ajoutez votre témoignage.
>
> Ayez du plaisir et participez en votant à
> https://loveopensource.crowdmap.com/main
> Ajoutez votre témoignage et répandez le virus à vos amis. J'invite chacun à
> écrire dans la langue qu'il maitrise le mieux.
>
> Si vous avez des contacts dans des agences de presse, svp transmettez-leur
> cette information. Si vous connaissez d'autres listes de distribution, svp,
> transmettez-leur cette information!
>
> J'aime les logiciels Libres, J'aime les données Libres, J'aime, J'aime ...
> I love Open Source, I love Open Data, I love, I love ...
>
>
> Pierre Béland
> HotOsm Humanitarian OpenStreetMap Team
> @pierzen
> http://hot.openstreetmap.org/weblog/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cyrille.

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

[OSM-talk-fr] Re : Présence sur le salon Primevère (Lyon) - 24/26 fév

[Otourly Wiki]

A confirmer mais je serais présent aussi.

 
Florian Farge aka Otourly
Sur lesprojets wikimédiens et l'Association française,OSM, et sur MOVIM
Socio di Wikimedia Italia




>
> De : Yves Rouquier 
>À : talk-fr@openstreetmap.org 
>Envoyé le : Mardi 14 février 2012 9h06
>Objet : Re: [OSM-talk-fr] Présence sur le salon Primevère (Lyon) - 24/26 fév
> 
>Bonjour ,
>
>L’association La Ville à Vélo présentera la carte des aménagements cyclables de
>la région lyonnaise réalisée avec OSM . ( http://carte.lavilleavelo.org/ ).
>
>Je suis aussi membre de l'ALDIL , Je prépare une version portable ( cle usb )
>de notre carte pour la mettre à disposition sur le stand de l'ALDIL.
>
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment augmenter le nombre de noms de commune affichés pour un certain niveau de zoom ?

[Stephane Klein]

Le 12/02/2012 22:58, yvecai a écrit :

Je pense qu'il faut modifier le style de carte, ce doit-être possible
chez Cloudmade: http://maps.cloudmade.com/editor


J'ai regardé cette interface d'édition de CloudMade et j'ai n'ai rien 
trouvé qui permette d'augmenter le nombre de noms de commune affichés 
pour un certain niveau de zoom.


Je n'ai trouvé que des options pour choisir les couleurs des éléments… 
les activés ou non…


Je pense que la solution doit se trouver ailleurs.

Cordialement,
Stéphane

--
Stéphane Klein 
blog: http://stephane-klein.info
Twitter: http://twitter.com/klein_stephane
pro: http://www.is-webdesign.com


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

Re: [OSM-talk-fr] J'aime les logiciels Libres, J'aime les données Libres, J'aime, J'aime ...

[Vincent Pottier]

Le 14/02/2012 05:16, Philippe Verdy a écrit :

Le 13 février 2012 23:47, Pieren  a écrit :

Y en a qui n'ont pas fumé que la moquette, là :)

Et ce Virus d'amour, qu'on appellera « Haute Intelligence des
Volontaires », donnera-t-il des "AIDS" à notre petite Communauté ?
Laissera-t-il des traces incurables chez nos Corps constitués, qui
croient protéger leurs SIG dans le secret du non-dit ? Et s'ils
trouvaient des thérapies multiples contre cette contamination qui n'a
rien d'accidentel ? Et doit-on s'attendre ensuite au dénigrement et à
la discrimination des données ? Il est temps de promouvoir des tests
libres et gratuits, et se battre contre les brevets qui envahissent et
polluent nos libertés.
Let's act up, now !


Y en a qui n'ont pas fumé que la moquette, là



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

Re: [OSM-talk-fr] MAIA : aires marines protégées

[partir-en-vtt]

15 coups de fouets aux dev dans ce cas

--
View this message in context: 
http://gis.19327.n5.nabble.com/MAIA-aires-marines-protegees-tp5478734p5482124.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] J'aime les logiciels Libres, J'aime les données Libres, J'aime, J'aime ...

[Hélène PETIT]

Le 13/02/2012 17:55, Pierre Béland a écrit :

*/Un virus d'amour se propage sur internet aujourd'hui/*


C'est marrant, j'ai bien aimé :>))

Mais je n'ai pas pu laisser de message, le site m'a planté firefox deux 
fois :>((

Je réésaierai un peu plus tard ...

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

[OSM-talk-fr] Litto3D : les fonds marins côtiers à 40 cm près

[Christian Rogel]

Ouest-France donne des détails sur l'opération du SHOM et de l'IGN appelée 
Litto3D qui consiste à cartographier précisément les côtes françaises.

- Le Finistère va être exploré, après Mayotte, la Martinique et le Golfe du 
Morbihan et la commande des relevés inclut aussi la Provence et la Côte d'Azur
- Les données en 3 D "seront accessibles à tous"
- Cela concerne le côté terre comme le côté mer (à 10 km et jusqu'à 20 m de 
profondeur avec une précision de 40 cm)
- 2 lidars (Light detection ranging) sont embarqués sur un avion qui explore 
des bandes de 290 m de large
- Coût pour le Finistère : 3 M € financés entièrement par l'Europe, l'Etat, la 
Région Bretagne, le Finistère et l'Agence des aires marines
- Le SHOM avait pour point 0 la plus basse mer et c'est le zéro de l'IGN (marée 
moyenne) qui va être retenu

Chef de projet au SHOM : Vincent Lamarre
Présentation : http://www.shom.fr/fr_page/fr_act_Litto3D/index_litto3D.htm

Article de Ouest-France Brest 14/02/12 : 
http://www.ouest-france.fr/actu/actuLocale_-Un-rayon-laser-pour-cartographier-le-littoral-_40734-2044423--29019-aud_actu.Htm


Christian (sans tirets)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] MAIA : aires marines protégées

[Philippe Verdy]

Pourtant les même développeurs affichent les copyrights des couches
"MPA" et "Bathymétrique".

Mais justement, le fond de carte ne fait pas partie des couches
(dés)activables puisque ce fond est toujours affiché de façon pleine
(non transparente) et toujours en arrière-plan, quoi qu'on choisisse.

Les développeurs ne savent pas positionner les copyrights affichés par
les différentes couches pour qu'ils ne superposent pas, mais
apparaissent dans une couche unique en avant-plan, dans un seul texte
fusionnant les mentions légales nécessaires.

Dans ce cas, il devrait afficher ces copyrights respectifs dans la
liste des couches à gauche, et inclure le fond OSM dans une couche
séparée listée dans cette même liste, et qu'on pourrait aussi cacher,
ou rendre semi-transparente pour ka passer devant la couche relief.

Pour moi cela montre d'abord que leur logiciel n'est pas fini, c'est
encore une démo, qui d'ailleurs fait l'objet de la présentation
publique demain soir dans la conférence-cocktail à Brest, où ce qui
sera présenté n'est pas réellement OSM, ni toutes les couches, mais la
couche MAP (dont ils mentionnent le copyright, alors qu'ils ne mettent
rien sur les autres couches dont MAIA est aussi l'auteur ou pour les
couches ayant d'autres origines, telles que les limites
administratives)

Note: la couche désignée comme "frontières adminsitratives" utilise
non pas les frontières des eaux territoriales, à peu près stables et
non contestées autour de la France métropolitaine, mais celles de «
l'extension du plateau continental » : ces dernières frontières sont
encore très contestées et non ratifiées par traité ou procédure devant
un tribunal international, notamment la ligne de séparation du plateau
continental français avec avec celui réclamé par l'Espagne, mais aussi
des eaux que d'autres pays (y compris Européens n'ayant pas de
frontière atlantique ni même aucune frontière maritime) considèrent
toujours comme des eaux internationales, notamment ceux qui y font
circuler des navires (la désignation de cette frontière n'est pas
claire du tout sur cette couche de leur carto)?

Les pays se disputent encore le droit de savoir qui a le droit
d'exploiter ce plateau continental (et l'Union européenne elle-même ne
peut rien y changer, elle n'a pas la compétence dans ce domaine pour
statuer, et jusqu'à présent la Cours internationale de justice de La
Haye (de même que l'ONU) refuse de se prononcer sur le fond de cette
question, mais ne traite que de litiges compensatoires entre deux
parties concernant les droits exclusifs d'accès et d'exploitation sur
les "eaux territoriales", et seulement si les pays en litige ont
choisi de présenter le règlement de ce litige devant cette Cour
arbitrale).

Le 14 février 2012 12:04, partir-en-vtt  a écrit :
> 15 coups de fouets aux dev dans ce cas
>
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/MAIA-aires-marines-protegees-tp5478734p5482124.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] [OSM-talk-fr-bzh] Litto3D : les fonds marins côtiers à 40 cm près

[Steven Le Roux]

SHOM + IGN, on n'est pas près de voir un import de ces nouvelles
côtes... on aura peut être un WMS avec un peu de chance :)


2012/2/14 Christian Rogel :
> Ouest-France donne des détails sur l'opération du SHOM et de l'IGN appelée 
> Litto3D qui consiste à cartographier précisément les côtes françaises.
>
> - Le Finistère va être exploré, après Mayotte, la Martinique et le Golfe du 
> Morbihan et la commande des relevés inclut aussi la Provence et la Côte d'Azur
> - Les données en 3 D "seront accessibles à tous"
> - Cela concerne le côté terre comme le côté mer (à 10 km et jusqu'à 20 m de 
> profondeur avec une précision de 40 cm)
> - 2 lidars (Light detection ranging) sont embarqués sur un avion qui explore 
> des bandes de 290 m de large
> - Coût pour le Finistère : 3 M € financés entièrement par l'Europe, l'Etat, 
> la Région Bretagne, le Finistère et l'Agence des aires marines
> - Le SHOM avait pour point 0 la plus basse mer et c'est le zéro de l'IGN 
> (marée moyenne) qui va être retenu
>
> Chef de projet au SHOM : Vincent Lamarre
> Présentation : http://www.shom.fr/fr_page/fr_act_Litto3D/index_litto3D.htm
>
> Article de Ouest-France Brest 14/02/12 : 
> http://www.ouest-france.fr/actu/actuLocale_-Un-rayon-laser-pour-cartographier-le-littoral-_40734-2044423--29019-aud_actu.Htm
>
>
> Christian (sans tirets)
> ___
> Talk-fr-bzh mailing list
> talk-fr-...@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr-bzh



-- 
Steven Le Roux
Jabber-ID : ste...@jabber.fr
0x39494CCB 
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB

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

Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet

[teuxe]

Bonjour,

Alors en lisant tout ça, et en partageant le point de vue, j'aurais tendance à 
dire +10...

C'est vrai, ça permet de découper le travail de création des cartes, ça permet 
de créer des combinaisons de layers plus facilement avec un client, des layers 
qui peuvent être customisables en SVG, etc.

Après réflexion, il y a des problèmes majeurs qui se posent comme toujours, 
dans le rendu :
- C'est bien quand il s'agit de dessiner des zones colorées d'arrière-plan, 
genre landuse/natural, ou des délimitations qui se superposent bien au reste, 
genre frontières, mais ça devient moins pratique pour tous les aspects de 
superposition (tag "layer") car l'information disparaît dans la séparation des 
tuiles.
- Comment définir quel tag va dans quelle couche ?
- Où placer les textes ? Sur la même tuile que les surfaces ? Sur une tuile à 
part, avec tous les textes ? Sur une tuile à part, dédiée càd ne contenant que 
les textes d'un layer donné ?
- Comment assurer que deux textes ne vont pas se superposer si les calculs des 
tuiles deviennent indépendants ? A moins que le rendu ne prenne en compte 
toutes les données affichables (càd le maximum de tuiles superposées)...

Cependant, si on trouve des réponses pratiques à toutes ces questions, les 
moteurs de rendu OSM auraient grand intérêt à mettre en place ce principe :)

Teuxe


- Mail Original -
De: "Philippe Verdy" 
À: "Discussions sur OSM en français" 
Envoyé: Lundi 13 Février 2012 20h44:39 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place 
= locality / hamlet

Plutôt que vouloir tout mettre ans Mapnik, je verrais plutôt le
développement de tuiles transparentes, superposables en couches
sélectionnables, et permettant d'afficher ou masquer ce que l'on veut
voir ou pas.

Bref des tuiles pour le fond topographique, des tuiles pour uniquement
les limites administratives, des tuiles semi-transparentes pour
colorer les "landuse", des tuiles transparentes pour la bâti, des
tuiles pour les libellés de chaque langue.

L'intérêt ? Moins compliqué de mettre à jour ces tuiles de façon
cohérente (malgré toutes les exceptions possibles qui peuvent
apparaître). Et une plus grande versatilité, et même des mises à jour
plus rapides (chaque jeu de tuiles pour un jeu de de données limité
peut être distribué sur des serveurs de rendu différents, qui ont
globalement moins de chose à faire).

Cependant le choix des couches de tuiles à visualiser demanderait une
interface plus conviviale que l'actuelle boite bleue déroulable, où ce
n'est qu'une simple liste, qui demanderait à devenir une liste
hiérarchique (un peu à la façon de ce qu'on voit dans Google Earth,
l'application "standalone", qui permet de sélectionner les couches qui
nous intéressent.

D'ailleurs ces tuiles spécialisées pourraient non pas être générées en
format bitmap (PNG, GIF, JPG), mais en SVG bien plus versatile, dont
le "stylage" peut être effectué sous le contrôle du client qui
pourrait encore dynamiquement changer les couleurs ou les épaisseurs
de traits, ou les polices utilisées, ou les styles et tailles de
police selon les préférences de chacun (et aussi ses propres options
d'accessibilité), simplement avec du CSS facile à maintenir en
Javascript. On peut noter que la prise en charge de SVG s'est
considérablement amélioré dans les navigateurs, et que SVG s'intègre
maintenant nativement dans le DOM pour HTML5, sans plugin
supplémentaire.

De quoi déprécier largement les tuiles bitmap actuellement distribuées
(et aussi faire gagner de la bande passante sur les serveurs de
tuiles), car dans bon nombre de cas, ces tuiles pourraient fonctionner
aussi de façon plus lisible pour des gammes étendues et non discrètes
d'échelles.

D'ailleurs Google se met aussi maintenant au rendu vectoriel de ses
tuiles (avec son option "MapGL" encore en beta-test), tout en
supportant maintenant le rendu multicouches (avec couches
sélectionnables) depuis longtemps dans Google Earth.

Une telle interface améliorée conviendrait aussi bien à ceux qui
veulent voir une carte lisible, que pour les contributeurs qui veulent
voir un maximum de choses, tout en facilitant aussi la sélection (par
clic sur la carte) des éléments à modifier, corriger, ou ajouter.

Je dirais même que cela améliorerait grandement la cohérence des tags
dans la base centrale OSM qui contient tous les objets servant de
source pour les différents moteurs de rendu (certes on ne "tague" pas
pour un rendu spécifique, mais tout rendu a besoin d'une cohérence des
données, et cela n'empêchera pas d'appliquer différents styles visuels
pour ce que chaque moteur décide ou non d'afficher dans ses tuiles).

A terme, cela pourrait même rendre l'utilisation de JOSM inutile (car
en fait bien trop complexe à utiliser quand il veut tout afficher en
même temps et ne facilite pas du tout la sélection d'objets superposés
ou qui partagent des noeuds ou traits communs, dans des zon

Re: [OSM-talk-fr] MAIA : aires marines protégées

[partir-en-vtt]

J'avais effectivement remarqué que la couche n'était pas présente.

Merci pour les autres détails.

J'espère que durant lors présentation, ils parleront du projet OSM !

--
View this message in context: 
http://gis.19327.n5.nabble.com/MAIA-aires-marines-protegees-tp5478734p5483391.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-talk-fr] Taguer les terrains vagues

[Séverin MENARD]

Bonjour,

Jee n'ai pas trouvé dans les map features un tag pour les terrains vagues
en milieu urbain. Un endroit très chouette, aurait pourtant dit le Petit
Nicolas.

Cordialement,

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

Re: [OSM-talk-fr] Taguer les terrains vagues

[Ab_fab]

vague ? hmmm," landuse = fuzzy" ?

ok, je déconne.

Pourquoi pas ça plutôt :
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbrownfield
http://wiki.openstreetmap.org/wiki/Proposed_features/Wasteland

Le 14 février 2012 23:00, Séverin MENARD  a écrit
:

> Bonjour,
>
> Jee n'ai pas trouvé dans les map features un tag pour les terrains vagues
> en milieu urbain. Un endroit très chouette, aurait pourtant dit le Petit
> Nicolas.
>
> Cordialement,
>
> Severin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Taguer les terrains vagues

[Pieren]

2012/2/14 Séverin MENARD :

> Jee n'ai pas trouvé dans les map features un tag pour les terrains vagues en
> milieu urbain.

landuse=brownfield/greenfield ?

Pieren

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

Re: [OSM-talk-fr] Taguer les terrains vagues

[Philippe Verdy]

Plutôt "wasteland" en anglais. Mais on en parle dans le wiki sur
Tag:landuse=brownfield et dans Tag:landuse=construction.

Pour moi les browfields sont des zones laissées à l'abandon, autrefois
occupées, souvent avec des ruines. Un vrai terrain vague est resté une
zone naturelle, autrefois peut-être une terre agricole qui s'est
retrouvée enfermée dans un paysage urbanisé, mais qu'on a décidé de
laisser à l'état vert, sans forcément l'aménager comme un vrai parc.
Leur avenir est incertain tant la pression urbaine voudrait les lotir.

Mis certaines communes ont pris les devants pour justement ne pas y
autoriser la construction, et au moins les protéger pour éviter
qu'elles se transforment en décharges (ce que pourrait évoquer le
terme anglais "wasteland").

Difficile à mapper. Car s'il y a une vraie protection, les communes
préfèrent en faire de vrais parcs nettoyés, et pas squattés, même si
les cultures restent encore assez sauvages (hautes herbes, arbres
désordonnés, talus, ronces... car ce sont des terres intéressantes
surtout en zone humide pour la nidification, et les petites espèces de
rongeurs que pourtant on supporte mal dans nos villes, alors que ce
sont de grands nettoyeurs !)

Le 14 février 2012 23:38, Pieren  a écrit :
> 2012/2/14 Séverin MENARD :
>
>> Jee n'ai pas trouvé dans les map features un tag pour les terrains vagues en
>> milieu urbain.
>
> landuse=brownfield/greenfield ?
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] le rendu map...@osm.org affiche si ou ça. Etait :place = locality / hamlet

[Philippe Verdy]

Le 14 février 2012 18:32,   a écrit :
> Bonjour,
>
> Alors en lisant tout ça, et en partageant le point de vue, j'aurais tendance 
> à dire +10...
>
> C'est vrai, ça permet de découper le travail de création des cartes, ça 
> permet de créer des combinaisons de layers plus facilement avec un client, 
> des layers qui peuvent être customisables en SVG, etc.
>
> Après réflexion, il y a des problèmes majeurs qui se posent comme toujours, 
> dans le rendu :
> - C'est bien quand il s'agit de dessiner des zones colorées d'arrière-plan, 
> genre landuse/natural, ou des délimitations qui se superposent bien au reste, 
> genre frontières, mais ça devient moins pratique pour tous les aspects de 
> superposition (tag "layer") car l'information disparaît dans la séparation 
> des tuiles.
> - Comment définir quel tag va dans quelle couche ?

C'est à chaque moteur de rendu de définir le nombre de couches
indépendantes de tuiles qu'il va générer, et dans quelle couche il va
placer les éléments qu'il trouve.

> - Où placer les textes ? Sur la même tuile que les surfaces ? Sur une tuile à 
> part, avec tous les textes ? Sur une tuile à part, dédiée càd ne contenant 
> que les textes d'un layer donné ?

Je penche plutôt pour la séparation complète (dans un même moteur de
rendu) des libellés, notamment pour permettre de choisir dans quelle
langue les afficher, ou même choisir de ne pas les afficher tout en
affichant le reste.

> - Comment assurer que deux textes ne vont pas se superposer si les calculs 
> des tuiles deviennent indépendants ? A moins que le rendu ne prenne en compte 
> toutes les données affichables (càd le maximum de tuiles superposées)...

Là encore, si les tuiles sont servies par des moteurs dont le
développement est séparé, il est impossible de s'assurer que ces
textes ne se superposeront pas.

Cependant, comme ces tuiles seront servies dans des couches séparées,
on peut encore disposer d'une interface permettant de sélectionner
laquelle de ces couches afficher.

> Cependant, si on trouve des réponses pratiques à toutes ces questions, les 
> moteurs de rendu OSM auraient grand intérêt à mettre en place ce principe :)

Je le pense aussi, car cela simplifierait énormément l'utilisation des
cartes et le travail de modification ou création de données (vers
quelquechose de bien plus utilisable que le "bordel" qu'on voit dans
JOSM ou Potlatch, où tout se mélange et où il est difficile d'oublier
des choses à créer ou corriger), tout en assurant une bien meilleure
cohérence des données stockées dans la base (en permettant à chaque
couche modifiable dans l'interface de restreindre le jeu de tags et de
valeurs utilisables ou acceptables).

D'ailleurs on s'en rends compte puisque justement Osmose sert aussi à
offrir des vues séparées de plusieurs couches d'erreurs qu'il détecte.

Si on a pu développer Osmose pour générer des couches séparées, on
doit aussi pouvoir faire la même chose pour créer des couches
destinées cette fois au rendu correct et utilisable des cartes,
destinées cette fois non plus seulement aux contributeurs
cartographes, mais à fournir un résultat clair montrant ce que
l'auteur d'une carte veut réellement montrer (ce qui n'exclue pas pour
autant que cette carte affiché ne puisse pas être modifiée dans la
même interface sans avoir à charger toutes les autres données stockées
dans la base OSM.


Et j'imagine que si le développement de JOSM doit continuer, dans la
mesure où il dispose DÉJÀ d'un mécanisme de gestion de calques, mais
qu'il sous-utilise cette fonctionnalité : je suggérerais aux auteurs
de JOSM de commencer à réfléchir à leur utilisation beaucoup plus
systématique où les données chargées le seraient dans des sous-calques
(même si ces sous-calques sont enregistrés ensemble dans un même
fichier OSM et soumis ensembles à la base de données), classant
automatiquement ces données dans les bons sous-calques.

Dans certains cas (pas si rares en fait), il y aura des liaisons entre
les sous-calques, notamment concernant la position de certains noeuds
partagés qui doivent permettre de fixer des calques sur des positions
qui devraient être identiques (voire même le seront de façon
systématique avec le modèle de données actuelles) :

* Par exemple, une couche "frontières administratives", elle-même
découpée en plusieurs sous-couches pour chaque niveau différent,
devrait pouvoir partager les positions des noeuds entre ces
sous-couches.

* De même avec une couche routière, les routes désignées comme "voies
communales" devraient être découpées là où passe la frontière
communale, puisque c'est le point (partagé par le chemin de la route
et le chemin de la frontière) où cette route peut changer de numéro ou
de nom; de même pour le découpage des autoroutes avec les frontières
nationales, celui des routes départementales avec les frontières de
départements...

* Dans le cas des libellés, on a le cas des noms à traduire : on
devrait pouvoir disposer aussi dans JOSM d'une vue langue par langue
pour s'assurer