Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Juste pour vous signaler que j'ai mis à jour la visite guidée en y ajoutant les dernières nouveautés principales. http://umap.openstreetmap.fr/map/cquest/visite-guidee-du-rendu-osm-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Géniale cette visite guidée. Quelle bonne idée ! Le 25 avril 2013 15:46, Christian Quest cqu...@openstreetmap.fr a écrit : Juste pour vous signaler que j'ai mis à jour la visite guidée en y ajoutant les dernières nouveautés principales. http://umap.openstreetmap.fr/map/cquest/visite-guidee-du-rendu-osm-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ 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
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Salut, et encore merci :-) Le 25/04/2013 10:46, Christian Quest a écrit : Juste pour vous signaler que j'ai mis à jour la visite guidée en y ajoutant les dernières nouveautés principales. http://umap.openstreetmap.fr/map/cquest/visite-guidee-du-rendu-osm-fr Je me demandais comme ça si ce ne serait pas un plus de faire apparaître à certains niveaux de zoom une petite ancre pour les ports, peut-être accompagnée du nom du port. Certes ça n'apparaît pas dans Mapnik ! @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
J'ai remarqué que les icônes des hôpitaux ne sont pas différencié en fonction de leur service d'urgence ou pas. On pourrait mettre une icône spécifique pour les hôpitaux prennent en charge les urgences? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Salut, Quand on regarde la Guyane française, par exemple au zoom 18, avec le rendu Mapnik ou FR, c'est le grand vide. Pas de noms comme Guyane ou Cayenne. Les rendu 2u ou Mapquest renseignent quand même mieux. Donc pour abuser, y'aurait pas moyen de moyenner quelque chose dans le rendu FR pour éviter l'angoisse du vide ? Merci Christian ;-) @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Un petit permalien pour aider ? Sur le zoom 18, ce genre d'info n'a pas beaucoup de pertinence... j'ai du mal à comprendre. Le 21 mars 2013 15:04, Stéphane MARTIN st3ph.mar...@laposte.net a écrit : Salut, Quand on regarde la Guyane française, par exemple au zoom 18, avec le rendu Mapnik ou FR, c'est le grand vide. Pas de noms comme Guyane ou Cayenne. Les rendu 2u ou Mapquest renseignent quand même mieux. Donc pour abuser, y'aurait pas moyen de moyenner quelque chose dans le rendu FR pour éviter l'angoisse du vide ? Merci Christian ;-) @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 21/03/2013 11:15, Christian Quest a écrit : Un petit permalien pour aider ? Sur le zoom 18, ce genre d'info n'a pas beaucoup de pertinence... j'ai du mal à comprendre. Le 21 mars 2013 15:04, Stéphane MARTIN st3ph.mar...@laposte.net a écrit : Salut, Quand on regarde la Guyane française, par exemple au zoom 18, avec le rendu Mapnik ou FR, c'est le grand vide. Pas de noms comme Guyane ou Cayenne. Les rendu 2u ou Mapquest renseignent quand même mieux. Donc pour abuser, y'aurait pas moyen de moyenner quelque chose dans le rendu FR pour éviter l'angoisse du vide ? Merci Christian ;-) Me suis sans doute planté dans le zoom. Désolé :-( http://tile.openstreetmap.fr/?zoom=8lat=4.07937lon=-54.35198layers=B0 http://tile.openstreetmap.fr/?zoom=5lat=1.84678lon=-49.9547layers=B0 Bref, en zappant entre osmfr et 2u on voit une différence. Je comprends bien que ça peut poser problème de faire apparaître les noms d'un département français et de sa préfecture au milieu de noms de pays avec leur capitale. D'ailleurs le mieux serait peut-être de faire apparaître Guyane française (l'appellation French Guyana semble internationalement adoptée) à certains niveaux de zoom sans que ça mette le bord... dans la base ou que ce soit étiqueté pour le rendu. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Je n'ai quasiment pas touché ces niveaux de zoom... ça vaut un ticket ;) Le 21 mars 2013 17:00, Stéphane MARTIN st3ph.mar...@laposte.net a écrit : Le 21/03/2013 11:15, Christian Quest a écrit : Un petit permalien pour aider ? Sur le zoom 18, ce genre d'info n'a pas beaucoup de pertinence... j'ai du mal à comprendre. Le 21 mars 2013 15:04, Stéphane MARTIN st3ph.mar...@laposte.net a écrit : Salut, Quand on regarde la Guyane française, par exemple au zoom 18, avec le rendu Mapnik ou FR, c'est le grand vide. Pas de noms comme Guyane ou Cayenne. Les rendu 2u ou Mapquest renseignent quand même mieux. Donc pour abuser, y'aurait pas moyen de moyenner quelque chose dans le rendu FR pour éviter l'angoisse du vide ? Merci Christian ;-) Me suis sans doute planté dans le zoom. Désolé :-( http://tile.openstreetmap.fr/?zoom=8lat=4.07937lon=-54.35198layers=B0 http://tile.openstreetmap.fr/?zoom=5lat=1.84678lon=-49.9547layers=B0 Bref, en zappant entre osmfr et 2u on voit une différence. Je comprends bien que ça peut poser problème de faire apparaître les noms d'un département français et de sa préfecture au milieu de noms de pays avec leur capitale. D'ailleurs le mieux serait peut-être de faire apparaître Guyane française (l'appellation French Guyana semble internationalement adoptée) à certains niveaux de zoom sans que ça mette le bord... dans la base ou que ce soit étiqueté pour le rendu. @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 16 mars 2013 22:11, Ab_fab gamma@gmail.com a écrit : Une autre approche, pour bien gérer les couleurs entre les axes routiers ^^ http://bl.ocks.org/migurski/5130639 Source : http://mike.teczno.com/notes/postgreslessness-mapnik-vectiles.html Bonjour, Très impressionnant, avec de drôles d'effets :-/ Au delà du côté flashy, il y a les possibilités de tuiler les données OSM directement vers le client qui s'occupe du rendu. Cela semble le saint graal du rendu en ligne, même du rendu tout court car on pourrait se passer de base locale sous Tilemill par exemple. Pour les cartes en ligne on pourait passer de : OSM - Postgis - Mapnik + Style.xml - mod_tile - Openlayer.js - Carte glissante en ligne à OSM - Serveur de tuilage des données - mapnik.js + Style.xml - Carte glissante en ligne http://wiki.openstreetmap.org/wiki/Vector_tiles ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 18 mars 2013 11:29, Bruno Cortial bruno.cort...@laposte.net a écrit : Le 16 mars 2013 22:11, Ab_fab gamma@gmail.com a écrit : Une autre approche, pour bien gérer les couleurs entre les axes routiers ^^ http://bl.ocks.org/migurski/5130639 Source : http://mike.teczno.com/notes/postgreslessness-mapnik-vectiles.html Bonjour, Très impressionnant, avec de drôles d'effets :-/ Je ne trouve pas cela impressionnant, c'est tout bonnement inutilisable sauf pour une démo de geek japonais qui n'a pas peut non plus pour ses oreilles... Le seul truc un peu intéressant dessus c'est le rendu d'une direction de parcours (quoique c'est faux car les routes bidirectionnelles sont rendues selon leur direction de tracé dans la base au leiu d'afficher les deux sens) mais en aucun cas ce rendu n'indique la véritable topologie routière. Pour le reste ce n'est pas une carte, c'est inutilisable, pas moyen de répérer quoi que ce soit. C'est juste fait pour faire joli au goût de son créateur. Il faut le voir comme une création artistique (et une démo des possibilités techniques d'un moteur de rendu), rien de plus, car la géolocalisation n'a en fait sur ce rendu aucune importance, on pourrait afficher n'importe quel autre endroit du monde et on ne serait pas plus avancé. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 18 mars 2013 12:04, Philippe Verdy verd...@wanadoo.fr a écrit : c'est tout bonnement inutilisable Merci de ta contribution BrunoC ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
On 16/03/2013 01:22, Christian Quest wrote: - enfin, TileMill affiche le message d'erreur suivant : ERROR : Column tags does not exist Line 1: ...M (select way,natural,waterway,landuse,coalesce(tags-'nam... Ah oui... il faut une base osm2pgsql avec les tags en hstore (colonne tags justement)... à rajouter dans le readme. Bonjour, Merci Christian pour ta réponse rapide malgré l'heure avancée ! J'ai donc installé l'extension hstore et réimporté les données avec osm2pgsl et l'option -k . Il n'y a plus d'erreur sur la colonne tags, mais sur ref:INSEE. Postgis Plugin: PSQL error: ERROR: column ref:INSEE does not exist LINE 1: ...,st_length(way) as way_len, admin_level,boundary, ref:INSEE... Il doit encore manquer quelque chose ... Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Ah oui, zut, on utilise un fichier .style un peu différent qui contient quelques colonnes de plus. Je pense que c'est la seule que j'utilise. Remplace ref:INSEE par tags-'ref:INSEE' Le 16 mars 2013 09:22, Jean-Claude Repetto jrepe...@free.fr a écrit : On 16/03/2013 01:22, Christian Quest wrote: - enfin, TileMill affiche le message d'erreur suivant : ERROR : Column tags does not exist Line 1: ...M (select way,natural,waterway,landuse,coalesce(tags-'nam... Ah oui... il faut une base osm2pgsql avec les tags en hstore (colonne tags justement)... à rajouter dans le readme. Bonjour, Merci Christian pour ta réponse rapide malgré l'heure avancée ! J'ai donc installé l'extension hstore et réimporté les données avec osm2pgsl et l'option -k . Il n'y a plus d'erreur sur la colonne tags, mais sur ref:INSEE. Postgis Plugin: PSQL error: ERROR: column ref:INSEE does not exist LINE 1: ...,st_length(way) as way_len, admin_level,boundary, ref:INSEE... Il doit encore manquer quelque chose ... Jean-Claude -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
On 16/03/2013 09:35, Christian Quest wrote: Ah oui, zut, on utilise un fichier .style un peu différent qui contient quelques colonnes de plus. Je pense que c'est la seule que j'utilise. Remplace ref:INSEE par tags-'ref:INSEE' Ça marche, merci. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Une autre approche, pour bien gérer les couleurs entre les axes routiers ^^ http://bl.ocks.org/migurski/5130639 Source : http://mike.teczno.com/notes/postgreslessness-mapnik-vectiles.html Le 13 mars 2013 11:11, Christian Quest cqu...@openstreetmap.fr a écrit : Passer du rouge au vert par un dégradé va donner un truc pas joli joli... je pense qu'il vaut mieux réordonner les tracés. Le 13 mars 2013 10:09, Francescu GAROBY windu...@gmail.com a écrit : Je rebondis sur ta remarque, concernant le rendu des embranchements par-dessus les routes qu'ils rejoignent/quittent : pourrait-on imaginer un rendu dégradé, allant d'une couleur à l'autre (exemple : du rouge au vert, tout particulièrement dans le cas des voies d'accélération/décélération de la Montée des Soldats de ton dernier lien) ? Je sens que ça ne va pas être simple à faire, mais ça pourrait être une solution graphiquement plus agréable, d'autant qu'une voie d'accélération/décélération permet de passer d'une vitesse A à une vitesse B de manière progressive. Francescu -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
On 12/03/2013 21:50, Christian Quest wrote: Champagne ! J'ai eu ma première étoile de git grâce à Jocelyn et ybon (utile par ces temps de neige). Et voilà ce que ça donne: https://github.com/cquest/osmfr-cartocss Bonjour, Je viens d'installer osmfr-cartoss dans une VM osmgeo-live-6.5. J'ai quelques soucis : - les chemins d'accès aux fichiers sont absolus, j'ai dû les passer en relatif ; - la documentation (https://github.com/cquest/osmfr-cartocss#readme) indique que la base PostgreSQL s'appelle gis, mais dans le projet TileMill, elle s'appelle osm. J'ai donc modifié le projet en remplaçant osm par gis (j'ai dû aussi enlever le mot de passe et le nom d'utilisateur) ; - enfin, TileMill affiche le message d'erreur suivant : ERROR : Column tags does not exist Line 1: ...M (select way,natural,waterway,landuse,coalesce(tags-'nam... ^ Quelqu'un a-t-il réussi cette installation à partir de github ? Je précise que je n'ai pas eu de problèmes avec OpenStreetMap Carto, la carte s'affiche bien dans TileMill. Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 16 mars 2013 00:54, Jean-Claude Repetto jrepe...@free.fr a écrit : On 12/03/2013 21:50, Christian Quest wrote: Champagne ! J'ai eu ma première étoile de git grâce à Jocelyn et ybon (utile par ces temps de neige). Et voilà ce que ça donne: https://github.com/cquest/osmfr-cartocss Bonjour, Je viens d'installer osmfr-cartoss dans une VM osmgeo-live-6.5. J'ai quelques soucis : - les chemins d'accès aux fichiers sont absolus, j'ai dû les passer en relatif ; C'est un défaut de TileMill sur Mac, qui modifie les chemins d'accès sans rien dire. - la documentation (https://github.com/cquest/osmfr-cartocss#readme) indique que la base PostgreSQL s'appelle gis, mais dans le projet TileMill, elle s'appelle osm. J'ai donc modifié le projet en remplaçant osm par gis (j'ai dû aussi enlever le mot de passe et le nom d'utilisateur) ; Oubli de mise à jour du readme d'origine... - enfin, TileMill affiche le message d'erreur suivant : ERROR : Column tags does not exist Line 1: ...M (select way,natural,waterway,landuse,coalesce(tags-'nam... Ah oui... il faut une base osm2pgsql avec les tags en hstore (colonne tags justement)... à rajouter dans le readme. ^ Quelqu'un a-t-il réussi cette installation à partir de github ? Je précise que je n'ai pas eu de problèmes avec OpenStreetMap Carto, la carte s'affiche bien dans TileMill. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Ici http://umap.openstreetmap.fr/map/cquest/visite-guidee-du-rendu-osm-fr/#20/45.42033/4.42373je vois un drapeau noir... Qu'est-ce ? Il correspond on dirait à une mairie annexe... suis pas sûr que le symbole soit bien compris du grand public :-) 2013/3/14 Christian Quest cqu...@openstreetmap.fr Un début de visite guidée du rendu FR: http://umap.openstreetmap.fr/map/cquest/visite-guidee-du-rendu-osm-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Les dérives de rue : Des textes à promenades http://drivrsdu.fr/des-textes-a-promenades/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Oui, le drapeau gris foncé/noir correspond à une mairie. Je suis d'accord avec toi : ce n'est pas le symbole plus parlant... D'où ma proposition de mettre le drapeau du pays concerné : http://trac.openstreetmap.fr/ticket/236 Francescu Le 14 mars 2013 07:34, Ista Pouss ista...@gmail.com a écrit : Ici http://umap.openstreetmap.fr/map/cquest/visite-guidee-du-rendu-osm-fr/#20/45.42033/4.42373je vois un drapeau noir... Qu'est-ce ? Il correspond on dirait à une mairie annexe... suis pas sûr que le symbole soit bien compris du grand public :-) 2013/3/14 Christian Quest cqu...@openstreetmap.fr Un début de visite guidée du rendu FR: http://umap.openstreetmap.fr/map/cquest/visite-guidee-du-rendu-osm-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Les dérives de rue : Des textes à promenades http://drivrsdu.fr/des-textes-a-promenades/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Il me semble que le même symbole pour une mairie ou mairie annexe suffirait. Une icône représentant un hôtel de ville (conventionellement c'est une maison avec des colonnes en façade (ça peut ressembler aussi à un tribunal ou un parlement mais conventionellement un tribunal est plutôt représenté par le glaive et la balance(comme aussi les h$opitaux par la croix bleue, la pharmacie par le caducée, le supermarché par un caddie...).. Le même symbole pour les mairies, et toutes les assemblées parlementaires locales, départementales, régionales ou nationales ira très bien (on peut y inclure aussi les préfectures/sous-préfectures) Le 14 mars 2013 08:57, Francescu GAROBY windu...@gmail.com a écrit : Oui, le drapeau gris foncé/noir correspond à une mairie. Je suis d'accord avec toi : ce n'est pas le symbole plus parlant... D'où ma proposition de mettre le drapeau du pays concerné : http://trac.openstreetmap.fr/ticket/236 Un drapeau ne serait pas plus parlant. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Pour le symbole de la façade, c'est vrai que c'est parlant, mais il lui manque une précision, que le drapeau a le mérite d'avoir : les couleurs du pays concerné. On peut alors imaginer plusieurs solutions possibles : * une façade coloré des couleurs du drapeau (compliqué à faire, et peut-être pas lisible) ; * une façade + le drapeau (trop chargé, sans doute) ; * la façade ou (exclusif) le drapeau (mais on perd une des 2 infos) ; Pour les bâtiments locaux, départementaux, régionaux, j'avais un temps envisagé de proposer de mettre les couleurs de l'entité (armoiries de la ville, logo du département/de la région), mais là encore, je me disais que ça serait peut-être compliqué à lire (les armoiries d'une ville sont-elles bien connues, au moins de ses habitants ?) et ferait beaucoup d'icônes à ajouter... Francescu Le 14 mars 2013 09:35, Philippe Verdy verd...@wanadoo.fr a écrit : Il me semble que le même symbole pour une mairie ou mairie annexe suffirait. Une icône représentant un hôtel de ville (conventionellement c'est une maison avec des colonnes en façade (ça peut ressembler aussi à un tribunal ou un parlement mais conventionellement un tribunal est plutôt représenté par le glaive et la balance(comme aussi les h$opitaux par la croix bleue, la pharmacie par le caducée, le supermarché par un caddie...).. Le même symbole pour les mairies, et toutes les assemblées parlementaires locales, départementales, régionales ou nationales ira très bien (on peut y inclure aussi les préfectures/sous-préfectures) Le 14 mars 2013 08:57, Francescu GAROBY windu...@gmail.com a écrit : Oui, le drapeau gris foncé/noir correspond à une mairie. Je suis d'accord avec toi : ce n'est pas le symbole plus parlant... D'où ma proposition de mettre le drapeau du pays concerné : http://trac.openstreetmap.fr/ticket/236 Un drapeau ne serait pas plus parlant. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 14 mars 2013 09:46, Francescu GAROBY windu...@gmail.com a écrit : Pour les bâtiments locaux, départementaux, régionaux, j'avais un temps envisagé de proposer de mettre les couleurs de l'entité (armoiries de la ville, logo du département/de la région), mais là encore, je me disais que ça serait peut-être compliqué à lire (les armoiries d'une ville sont-elles bien connues, au moins de ses habitants ?) et ferait beaucoup d'icônes à ajouter... Si ça peut donner des idées, j'avais déjà essayé d'utiliser les blasons de wikipedia (projet au quel javais participé dans le temps ou je n'avais pas encore découvert OSM ;) ) pour les afficher sur une carte. http://map.carte-libre.fr/blason/ Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le drapeau c'est plutôt plutôt pour les ambassades, non ? On 14 mars 2013, at 09:46, Francescu GAROBY windu...@gmail.com wrote: Pour le symbole de la façade, c'est vrai que c'est parlant, mais il lui manque une précision, que le drapeau a le mérite d'avoir : les couleurs du pays concerné. On peut alors imaginer plusieurs solutions possibles : * une façade coloré des couleurs du drapeau (compliqué à faire, et peut-être pas lisible) ; * une façade + le drapeau (trop chargé, sans doute) ; * la façade ou (exclusif) le drapeau (mais on perd une des 2 infos) ; Pour les bâtiments locaux, départementaux, régionaux, j'avais un temps envisagé de proposer de mettre les couleurs de l'entité (armoiries de la ville, logo du département/de la région), mais là encore, je me disais que ça serait peut-être compliqué à lire (les armoiries d'une ville sont-elles bien connues, au moins de ses habitants ?) et ferait beaucoup d'icônes à ajouter... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Un buste de Marianne? Le 14/03/2013 09:54, Vladimir Vyskocil a écrit : Le drapeau c'est plutôt plutôt pour les ambassades, non ? On 14 mars 2013, at 09:46, Francescu GAROBY windu...@gmail.com wrote: Pour le symbole de la façade, c'est vrai que c'est parlant, mais il lui manque une précision, que le drapeau a le mérite d'avoir : les couleurs du pays concerné. On peut alors imaginer plusieurs solutions possibles : * une façade coloré des couleurs du drapeau (compliqué à faire, et peut-être pas lisible) ; * une façade + le drapeau (trop chargé, sans doute) ; * la façade ou (exclusif) le drapeau (mais on perd une des 2 infos) ; Pour les bâtiments locaux, départementaux, régionaux, j'avais un temps envisagé de proposer de mettre les couleurs de l'entité (armoiries de la ville, logo du département/de la région), mais là encore, je me disais que ça serait peut-être compliqué à lire (les armoiries d'une ville sont-elles bien connues, au moins de ses habitants ?) et ferait beaucoup d'icônes à ajouter... ___ 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] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 14 mars 2013 09:54, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Le drapeau c'est plutôt plutôt pour les ambassades, non ? Oui tout à fait. Mais sur ce point je choisirais une icône neutre indépendante du pays (d'autant plus que certaines ambassades représentent plusieurs pays simultanément, par convention entre ces pays, par exemple les représentation diplomatiques suisses sont souvent utilisées par d'autres pays qui n'ont pas de représentation consulaire dans un pays concerné, en zone de guerre par exemple ou suite à la décision d'un pays de se retirer, la Suisse faisant alors le relais, mais on a le cas aussi des représentation consulaires de divers pays européens dans le monde qui ont passé des conventions pour assurer certains services pour les expatriés d'autres pays européens ; la France le fait dans certains petits pays où elle est présente, et utilise aussi des services consulaires d'autres pays). Bref pour les ambassades l'icône serait plutôt deux drapeaux flottants, avec leur hampe, parallèles (évoquant la série de mats pour les drapeaux des membres devant l'ONU à NYC, ou devant le parlement de l'UE, ou devant deux de l'OTAN) ou bien croisés, et avec des couleurs neutres. Mettre des drapeaux nationaux divers un peu partout n'apportera pas plus de clarté à la carte quand de nombreux drapeaux ne sont pas reconnaissables facilement (ne pas oublier qu'on affiche aussi le libellé en clair). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
On confondrait avec n'importe quelle statue (les Mariannes n'arrêtent pas de changer de forme et de figures, elle n'est reconnaissable que dans sa dernière forme admise mais même selon les administrations françaises on la voit sous des traits divers, et ce sont alors des logos identifiants). On croirait qu'il y a une statue, une oeuvre d'art, voire tout un musée Le 14 mars 2013 10:06, CedricDV cedricdumezv...@gmail.com a écrit : Un buste de Marianne? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Et les préfectures/sous-prefecture ? Bon ce n'est qu'une suggestion mais pour l'instant elle ne sont pas iconisé, si cela surcharge les cartes ce n'est pas obligatoire. Le 14 mars 2013 10:19, Philippe Verdy verd...@wanadoo.fr a écrit : Le 14 mars 2013 09:54, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Le drapeau c'est plutôt plutôt pour les ambassades, non ? Oui tout à fait. Mais sur ce point je choisirais une icône neutre indépendante du pays (d'autant plus que certaines ambassades représentent plusieurs pays simultanément, par convention entre ces pays, par exemple les représentation diplomatiques suisses sont souvent utilisées par d'autres pays qui n'ont pas de représentation consulaire dans un pays concerné, en zone de guerre par exemple ou suite à la décision d'un pays de se retirer, la Suisse faisant alors le relais, mais on a le cas aussi des représentation consulaires de divers pays européens dans le monde qui ont passé des conventions pour assurer certains services pour les expatriés d'autres pays européens ; la France le fait dans certains petits pays où elle est présente, et utilise aussi des services consulaires d'autres pays). Bref pour les ambassades l'icône serait plutôt deux drapeaux flottants, avec leur hampe, parallèles (évoquant la série de mats pour les drapeaux des membres devant l'ONU à NYC, ou devant le parlement de l'UE, ou devant deux de l'OTAN) ou bien croisés, et avec des couleurs neutres. Mettre des drapeaux nationaux divers un peu partout n'apportera pas plus de clarté à la carte quand de nombreux drapeaux ne sont pas reconnaissables facilement (ne pas oublier qu'on affiche aussi le libellé en clair). ___ 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] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le problème avec Marianne n'est pas seulement qu'elle change tous les 4 matins, mais aussi qu'il n'existe pas de buste officiel : les communes peuvent faire faire le buste de n'importe quelle femme (certaines organisent des concours entre les habitantes de la commune). Il reste donc le profil de Marianne, utilisé sur les documents et sites Web officiels du gouvernement. Francescu Le 14 mars 2013 10:23, Philippe Verdy verd...@wanadoo.fr a écrit : On confondrait avec n'importe quelle statue (les Mariannes n'arrêtent pas de changer de forme et de figures, elle n'est reconnaissable que dans sa dernière forme admise mais même selon les administrations françaises on la voit sous des traits divers, et ce sont alors des logos identifiants). On croirait qu'il y a une statue, une oeuvre d'art, voire tout un musée Le 14 mars 2013 10:06, CedricDV cedricdumezv...@gmail.com a écrit : Un buste de Marianne? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 14 mars 2013 10:25, Jo. perche...@gmail.com a écrit : Et les préfectures/sous-prefecture ? Bon ce n'est qu'une suggestion mais pour l'instant elle ne sont pas iconisé, si cela surcharge les cartes ce n'est pas obligatoire. A mon avis pour les mairies, mairies annexes, assemblées communautaires, conseils généraux, régionaux, sous-préfectures et préfectures, et parlements nationaux, la même icône. On n'a pas tant de lieu que ça dans une même ville (sauf Paris en France, mais le niveau de détail demandé est tel que det toute façon il y aura des tas d'autres icônes et que pouvoir chercher une icone uique ne posera pas de problème). Une carte doit rester lisible, pas un patchwork. Le but de l'icone c'est d'identifier du premier coup d'oeil le type de service, mais pas un service précis. Les icônes doivent cependant rester assez discrètes pour ne pas surcharger le reste. Elles sont nécessairement alors assez petites et on ne peut pas afficher dessus beaucoup de détails. Une bonne icone devrait être pratiquement monochrome. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 14/03/2013 10:28, Francescu GAROBY a écrit : Le problème avec Marianne n'est pas seulement qu'elle change tous les 4 matins, mais aussi qu'il n'existe pas de buste officiel : les communes peuvent faire faire le buste de n'importe quelle femme (certaines organisent des concours entre les habitantes de la commune). Il reste donc le profil de Marianne, utilisé sur les documents et sites Web officiels du gouvernement. Effectivement, je pensait plutôt à ce profil mais me suis mal exprimé. Merci pour ce commentaire constructif. Cedric Francescu Le 14 mars 2013 10:23, Philippe Verdy verd...@wanadoo.fr mailto:verd...@wanadoo.fr a écrit : On confondrait avec n'importe quelle statue (les Mariannes n'arrêtent pas de changer de forme et de figures, elle n'est reconnaissable que dans sa dernière forme admise mais même selon les administrations françaises on la voit sous des traits divers, et ce sont alors des logos identifiants). On croirait qu'il y a une statue, une oeuvre d'art, voire tout un musée Le 14 mars 2013 10:06, CedricDV cedricdumezv...@gmail.com mailto:cedricdumezv...@gmail.com a écrit : Un buste de Marianne? ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ 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] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 14/03/2013 10:28, Francescu GAROBY a écrit : Il reste donc le profil de Marianne, utilisé sur les documents et sites Web officiels du gouvernement. Francescu Il y a toute une série de timbres avec le profil de Marianne : http://www.or-et-hconseil.com/wp-content/uploads/2011/03/historique_marianne.jpg Jean-Claude ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Je pensais à ce profil_là : http://diagauto91.fr/wp-content/uploads/2013/01/marianne.jpg Francescu Le 14 mars 2013 10:48, Jean-Claude Repetto jrepe...@free.fr a écrit : Le 14/03/2013 10:28, Francescu GAROBY a écrit : Il reste donc le profil de Marianne, utilisé sur les documents et sites Web officiels du gouvernement. Francescu Il y a toute une série de timbres avec le profil de Marianne : http://www.or-et-hconseil.com/**wp-content/uploads/2011/03/** historique_marianne.jpghttp://www.or-et-hconseil.com/wp-content/uploads/2011/03/historique_marianne.jpg Jean-Claude __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Rien à voir avec Marianne mais si vous voulez rendre ce rendu très populaire au Japon (arf), il suffirait d'afficher les noms des intersections qui peuvent être là-bas plus importants que les noms de rues: http://lists.openstreetmap.org/pipermail/talk/2013-February/066205.html http://lists.openstreetmap.org/pipermail/talk/2013-February/066226.html Le balisage hésite entre junction=yes et highway=junction + name. Une difficulté sera sans doute de gérer l'affichage du nom avec l'éventuelle présence d'un feu de circulation. Exemple sur gmaps: http://goo.gl/maps/4j6c8 Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Dans vos réflexions, pensez aussi aux tags permettant d'identifier ces POI... Quels tags pour différencier une marie d'une mairie annexe ? Quels tags pour une préfecture, une sous-préfecture, un CG, un CR... et tout ça pas que pour la France... building=* + amenity=public_building + admin_level=n ? Si jai mis un simple drapeau gris pour visualiser les mairies, c'est en pensant à un possible futur projet du mois: positionner les mairies manquantes ;) Chaque commune possédant une mairie (sauf quelques exceptions comme les villages Morts pour la France, mais on peut les retrouver grâce au population=0), ça devrait pouvoir se détecter facilement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 14 mars 2013 12:06, Pieren pier...@gmail.com a écrit : Rien à voir avec Marianne mais si vous voulez rendre ce rendu très populaire au Japon (arf), il suffirait d'afficher les noms des intersections qui peuvent être là-bas plus importants que les noms de rues: http://lists.openstreetmap.org/pipermail/talk/2013-February/066205.html http://lists.openstreetmap.org/pipermail/talk/2013-February/066226.html Le balisage hésite entre junction=yes et highway=junction + name. Une difficulté sera sans doute de gérer l'affichage du nom avec l'éventuelle présence d'un feu de circulation. Exemple sur gmaps: http://goo.gl/maps/4j6c8 Feu de passage qui sont effectivement plutôt horizontaux là bas ! Comme quoi, adapter un rendu à la culture locale est quand même bien utile. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Pour distinguer une mairie (celle qui accueille les sessions pleinières) d'une mairie annexe ou de bureaux, on pourrait rajouter quelque chose comme XXX=main et pour les bâtiments annexes XXX=secondary. XXX restant à définir. Pour les préfectures et sous-préfectures, la différenciation peut se faire de manière géographique : une préfecture est dans l'arrondissement où se trouve le chef-lieu de département/région, pas les sous-préfectures. Francescu Le 14 mars 2013 20:45, Christian Quest cqu...@openstreetmap.fr a écrit : Dans vos réflexions, pensez aussi aux tags permettant d'identifier ces POI... Quels tags pour différencier une marie d'une mairie annexe ? Quels tags pour une préfecture, une sous-préfecture, un CG, un CR... et tout ça pas que pour la France... building=* + amenity=public_building + admin_level=n ? Si jai mis un simple drapeau gris pour visualiser les mairies, c'est en pensant à un possible futur projet du mois: positionner les mairies manquantes ;) Chaque commune possédant une mairie (sauf quelques exceptions comme les villages Morts pour la France, mais on peut les retrouver grâce au population=0), ça devrait pouvoir se détecter facilement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 14/03/2013 20:59, Francescu GAROBY a écrit : Pour distinguer une mairie (celle qui accueille les sessions pleinières) d'une mairie annexe ou de bureaux, on pourrait rajouter quelque chose comme XXX=main et pour les bâtiments annexes XXX=secondary. XXX restant à définir. Pour les préfectures et sous-préfectures, la différenciation peut se faire de manière géographique : une préfecture est dans l'arrondissement où se trouve le chef-lieu de département/région, pas les sous-préfectures. Francescu Attention toutefois qu'une sous-préfecture, ce n'est pas une annexe de préfecture et qu'une marie annexe, ce n'est pas une sous-mairie. Dans une sous-préfecture, il y a un sous-préfet dans une mairie annexe, il n'y a ni sous-maire, ni maire-annexe (mais il y a peut-être un sous-marinier). -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 14 mars 2013 20:59, Francescu GAROBY windu...@gmail.com a écrit : Pour distinguer une mairie (celle qui accueille les sessions pleinières) d'une mairie annexe ou de bureaux, on pourrait rajouter quelque chose comme XXX=main et pour les bâtiments annexes XXX=secondary. XXX restant à définir. Pour les préfectures et sous-préfectures, la différenciation peut se faire de manière géographique : une préfecture est dans l'arrondissement où se trouve le chef-lieu de département/région, pas les sous-préfectures. Francescu Je la sentai venir celle là ;) Bien sûr qu'on peut déduire plein de choses de manière géographique, mais c'est particulièrement délicat dans bien des cas. Un petit tag, aide quand même beaucoup. Le tout relationnel et le tout géographique c'est beau sur le plan théorique, mais il faut aussi rester pratique et anticiper les cas particuliers où la seule géographie ne permettra pas de s'en sortir. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 14 mars 2013 20:59, Francescu GAROBY windu...@gmail.com a écrit : Pour les préfectures et sous-préfectures, la différenciation peut se faire de manière géographique : une préfecture est dans l'arrondissement où se trouve le chef-lieu de département/région, pas les sous-préfectures. Pas toujours. car on a le cas en France où la sous-préfecture n'est même pas dans son propre arrondissement (deux sous-préfectures au même endroit dans le même arrondissement), la différence étant alors uniquement dans les services avec des bueaux éventuellement à des étages différents, mais des points d'accueil du public en commun. De même pour les admin_centre des communes inhabitées (l'administration de ces communes est sous la responsaibilité du préfet), ou des territoires inhabités de façon permanente (par exemple Clipperton, administré depuis Papeete, ou les îles de l'océan indien qui forment un district des TAFF administré par un préfet et un conseil gouvermental à la Réunion). Si on veut savoir si un emplacement administratif correspondant à un POI est une mairie, on regarde l'admin_centre de la commune. Sinon c'est autre chose. Si on veut savoir si tous les départements ou arrondissements ont une préfecture indiquée quelquepart, on regarde là encore l'admin_centre (qui cependant ne renseigne que la commune où la préfecture ou sous-préfecture est située). L'ensemble aussi des batiments d'une préfecture peut être éclaté en divers endroits disjoints. S'il le faut on pourrait créer une relation englobant les différentes implantations, tout en induquant aussi un noeud admin_center pour son adresse principale. Là où ça se complique c'est que les bâtiments administratifs de différentes entités peuvent être au même endroit, les entités légales se partageant les locaux et parfois même du personnel (ensuite c'est une question de gestion et de répartition des budgets et charges d'exploitation)... Et en fin de compte ce qu'on retient alors c'est le libellé descriptif communément utilisé localement (même si pour les question légales, les services ont des adresses postales différentes et des noms de services différenciés). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Pour les pull-request, il faut que je passe ma deuxième étoile de git... mais j'ai de bons moniteurs ;) Tu verra, c'est facile de compléter pour ce genre de chose pour les transport publics, il faut par contre que les données soient cohérentes. Une petite modif dans le style et un picto. Sur Paris il manque beaucoup de logos bus sur les arrêts RATP. C'est comme les logo SNCF sur les gares, si il n'y a pas operator=SNCF ils ne seront pas rendus, comme La Poste pour les bureaux de poste... c'est au moins un avantage de rendre certaines infos, on voit plus facilement lorsqu'elles manquent ;) Le 12 mars 2013 21:55, Francescu GAROBY windu...@gmail.com a écrit : Cool !!! Bon, attends-toi à te faire bombarder de pull-requests : j'ai bien envie de personnaliser les logos pour les transports en commun de l'agglomération caennaise + quelques autres petites idées :-) Francescu -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Je rebondis sur ta remarque, concernant le rendu des embranchements par-dessus les routes qu'ils rejoignent/quittent : pourrait-on imaginer un rendu dégradé, allant d'une couleur à l'autre (exemple : du rouge au vert, tout particulièrement dans le cas des voies d'accélération/décélération de la Montée des Soldats de ton dernier lien) ? Je sens que ça ne va pas être simple à faire, mais ça pourrait être une solution graphiquement plus agréable, d'autant qu'une voie d'accélération/décélération permet de passer d'une vitesse A à une vitesse B de manière progressive. Francescu Le 12 mars 2013 22:12, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Dans le genre plat de spaghetti, sur Lyon on a ça: http://tile.openstreetmap.fr/?zoom=17lat=45.77177lon=4.78927layers=B0 c'est rendu plutôt bien en fait ! un détail quand même: aux entrées/sorties de tunnel, la réalité correspondrait plus à un bout de ligne droit que arrondi ... chose que l'on retrouve également ici: http://tile.openstreetmap.fr/?zoom=18lat=45.75133lon=4.82329layers=B0 autre détail en regardant de plus près: la gestion des embranchements dans le cas de voies de niveau hiérarchique différent. ex ici (c’est aussi un peu visible sur les liens précédents): http://tile.openstreetmap.fr/?zoom=17lat=45.78947lon=4.86672layers=B0 au nord-est, le rond-point est coupé par 2 voies d'un niveau différents. au sud-ouest, les embranchements du périph recouvrent complétement la route normale. Dans l'idéal, il faudrait que les embranchements soient rendus en premier, puis les routes dont l'axe principal est rectiligne ;) ... mais bon, le requête sql ne doit pas être si simple ! Sylvain Le 12 mars 2013 21:55, Francescu GAROBY windu...@gmail.com a écrit : Cool !!! Bon, attends-toi à te faire bombarder de pull-requests : j'ai bien envie de personnaliser les logos pour les transports en commun de l'agglomération caennaise + quelques autres petites idées :-) Francescu Le 12 mars 2013 21:50, Christian Quest cqu...@openstreetmap.fr a écrit : Champagne ! J'ai eu ma première étoile de git grâce à Jocelyn et ybon (utile par ces temps de neige). Et voilà ce que ça donne: https://github.com/cquest/osmfr-cartocss -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ 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 -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Passer du rouge au vert par un dégradé va donner un truc pas joli joli... je pense qu'il vaut mieux réordonner les tracés. Le zoom 19 rend visible ces détails, comme celui des secondary/tertiary qui connectés à un tunnel on leur bordure visible. Je l'ai supprimée, car elle n'est utile que pour les culs de sac et on ne devrait pas en avoir sur les secondary/tertiary. Je l'ai laissé sur les residential, unclassified, etc en attendant de mieux les gérer. Je suis en train d'explorer le z_order généré par osm2pgsql (voir https://github.com/openstreetmap/osm2pgsql/blob/master/output-pgsql.c#L310) Le classement se fait par type de highway (motorway, trunk, primary, secondary, tertiary, residential, unclassified, road et minor), puis est ajouté 10 pour bridge=yes, -10 pour tunnel=yes et layer*10 est ajouté. Les _link sont donc mis au même niveau que leur type de base... alors qu'il serait plutôt souhaitable de les traiter à part. Je vais essayer de recalculer un z_order via SQL, ça doit avoir un impact marginal en charge de calcul et de voir ce que ça donne au niveau de la cohérence du rendu... Le 13 mars 2013 10:09, Francescu GAROBY windu...@gmail.com a écrit : Je rebondis sur ta remarque, concernant le rendu des embranchements par-dessus les routes qu'ils rejoignent/quittent : pourrait-on imaginer un rendu dégradé, allant d'une couleur à l'autre (exemple : du rouge au vert, tout particulièrement dans le cas des voies d'accélération/décélération de la Montée des Soldats de ton dernier lien) ? Je sens que ça ne va pas être simple à faire, mais ça pourrait être une solution graphiquement plus agréable, d'autant qu'une voie d'accélération/décélération permet de passer d'une vitesse A à une vitesse B de manière progressive. Francescu Le 12 mars 2013 22:12, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Dans le genre plat de spaghetti, sur Lyon on a ça: http://tile.openstreetmap.fr/?zoom=17lat=45.77177lon=4.78927layers=B0 c'est rendu plutôt bien en fait ! un détail quand même: aux entrées/sorties de tunnel, la réalité correspondrait plus à un bout de ligne droit que arrondi ... chose que l'on retrouve également ici: http://tile.openstreetmap.fr/?zoom=18lat=45.75133lon=4.82329layers=B0 autre détail en regardant de plus près: la gestion des embranchements dans le cas de voies de niveau hiérarchique différent. ex ici (c’est aussi un peu visible sur les liens précédents): http://tile.openstreetmap.fr/?zoom=17lat=45.78947lon=4.86672layers=B0 au nord-est, le rond-point est coupé par 2 voies d'un niveau différents. au sud-ouest, les embranchements du périph recouvrent complétement la route normale. Dans l'idéal, il faudrait que les embranchements soient rendus en premier, puis les routes dont l'axe principal est rectiligne ;) ... mais bon, le requête sql ne doit pas être si simple ! Sylvain Le 12 mars 2013 21:55, Francescu GAROBY windu...@gmail.com a écrit : Cool !!! Bon, attends-toi à te faire bombarder de pull-requests : j'ai bien envie de personnaliser les logos pour les transports en commun de l'agglomération caennaise + quelques autres petites idées :-) Francescu Le 12 mars 2013 21:50, Christian Quest cqu...@openstreetmap.fr a écrit : Champagne ! J'ai eu ma première étoile de git grâce à Jocelyn et ybon (utile par ces temps de neige). Et voilà ce que ça donne: https://github.com/cquest/osmfr-cartocss -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ 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 -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 13 mars 2013 11:11, Christian Quest cqu...@openstreetmap.fr a écrit : Les _link sont donc mis au même niveau que leur type de base... alors qu'il serait plutôt souhaitable de les traiter à part. Je vais essayer de recalculer un z_order via SQL, ça doit avoir un impact marginal en charge de calcul et de voir ce que ça donne au niveau de la cohérence du rendu... ah ben si c'est aussi simple que ça ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Un début de visite guidée du rendu FR: http://umap.openstreetmap.fr/map/cquest/visite-guidee-du-rendu-osm-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
On 11 mars 2013, at 21:45, Philippe Verdy verd...@wanadoo.fr wrote: As-tu un exemple concret quelque part où tu voies réellement la boursouflure que tu décris ? A mon avis si tu la vois c'est que les voies après la séparation n'ont pas seulement la différence oneway=yes mais ont changé de nature (bref un problème de données existantes mais pas un problème du rendu actuel). Je parle de ce genre de choses : http://www.openstreetmap.org/browse/node/307405994 Ici par exemple l'emprise de la chaussée est a peu près équivalent avant et apres la séparation des deux voies mais le rendu exagère beaucoup la différence alors que si la largeur des voies à sens unique étaient divisisé par deux cela serait plus proche de la réalité Vlad.___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le rendu ne fait que transcrire les données qui à mon avis exagèrent l'angle dans le cas que tu indiques... on a vraiment l'impression qu'il y a comme une chicane. Je pense que le raccord entre traits épais et fins risque d'être délicat, mais rien n'est impossible, c'est juste un peu plus compliqué à traiter pour que ça soit graphiquement propre. Le 12 mars 2013 08:50, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : On 11 mars 2013, at 21:45, Philippe Verdy verd...@wanadoo.fr wrote: As-tu un exemple concret quelque part où tu voies réellement la boursouflure que tu décris ? A mon avis si tu la vois c'est que les voies après la séparation n'ont pas seulement la différence oneway=yes mais ont changé de nature (bref un problème de données existantes mais pas un problème du rendu actuel). Je parle de ce genre de choses : http://www.openstreetmap.org/browse/node/307405994 Ici par exemple l'emprise de la chaussée est a peu près équivalent avant et apres la séparation des deux voies mais le rendu exagère beaucoup la différence alors que si la largeur des voies à sens unique étaient divisisé par deux cela serait plus proche de la réalité Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Bonjour tout le monde, Sympa ce rendu ; merci. Concernant le lissage au zoom 19, ça donne un rendu très particulier : http://tile.openstreetmap.fr/?zoom=19lat=48.72586lon=4.58526layers=B0 vous en avez peut être parlé sur les tickets (j'*ai un peu de mal à comprendre le fonctionnement*), et c'est déjà en cours de traitement? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
J'ai la même à Caen : http://tile.openstreetmap.fr/?zoom=19lat=49.18171lon=-0.37274layers=B0 Les arrondis ne se font que sur des angles qui ne sont pas à 90° ? C'est du moins ce que je déduis de mes premières recherches... De toute façon, il y aura toujours des virages (quelque soit l'angle) dont le tracé est vraiment un angle, et non pas une courbe. Comment faire la distinction ? Un tag de plus sur le(s) node(s) qui fait(font) l'angle (du genre smooth=yes/no) ?!? Francescu Le 12 mars 2013 09:30, Simon Miniou simon.min...@gmail.com a écrit : Bonjour tout le monde, Sympa ce rendu ; merci. Concernant le lissage au zoom 19, ça donne un rendu très particulier : http://tile.openstreetmap.fr/?zoom=19lat=48.72586lon=4.58526layers=B0 vous en avez peut être parlé sur les tickets (j'*ai un peu de mal à comprendre le fonctionnement*), et c'est déjà en cours de traitement? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Bravo pour le travail ! Juste une question : pourquoi les primary_link sont-elle tracées avec un trait noir en plein milieu ? Comme ici : http://tile.openstreetmap.fr/?zoom=19lat=49.18318lon=-0.38658layers=B0et là : http://tile.openstreetmap.fr/?zoom=19lat=49.18546lon=-0.38354layers=B0 Francescu Le 12 mars 2013 09:14, Christian Quest cqu...@openstreetmap.fr a écrit : Le rendu ne fait que transcrire les données qui à mon avis exagèrent l'angle dans le cas que tu indiques... on a vraiment l'impression qu'il y a comme une chicane. Je pense que le raccord entre traits épais et fins risque d'être délicat, mais rien n'est impossible, c'est juste un peu plus compliqué à traiter pour que ça soit graphiquement propre. Le 12 mars 2013 08:50, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : On 11 mars 2013, at 21:45, Philippe Verdy verd...@wanadoo.fr wrote: As-tu un exemple concret quelque part où tu voies réellement la boursouflure que tu décris ? A mon avis si tu la vois c'est que les voies après la séparation n'ont pas seulement la différence oneway=yes mais ont changé de nature (bref un problème de données existantes mais pas un problème du rendu actuel). Je parle de ce genre de choses : http://www.openstreetmap.org/browse/node/307405994 Ici par exemple l'emprise de la chaussée est a peu près équivalent avant et apres la séparation des deux voies mais le rendu exagère beaucoup la différence alors que si la largeur des voies à sens unique étaient divisisé par deux cela serait plus proche de la réalité Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 12/03/2013 09:56, Francescu GAROBY a écrit : Bravo pour le travail ! Juste une question : pourquoi les primary_link sont-elle tracées avec un trait noir en plein milieu ? Comme ici : http://tile.openstreetmap.fr/?zoom=19lat=49.18318lon=-0.38658layers=B0 et là : http://tile.openstreetmap.fr/?zoom=19lat=49.18546lon=-0.38354layers=B0 Francescu Étrange là aussi : http://tile.openstreetmap.fr/?zoom=19lat=46.36865lon=5.95777layers=B0 Double rendu du chemin. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Juste une question : pourquoi les primary_link sont-elle tracées avec un trait noir en plein milieu ? Quand les deux directions d'une route sont mappées séparément, un chemin par direction, le résultat sur le rendu dépend de la distance des deux chemins. Quand ils sont à une distance inférieure à la largeur de la voie on ne voit pas les bords noirs. Quand ils ont plus de distance, on les voit. En général, et je suppose que Christian fait pareil, on trace d'abord un gros trait noir et puis un trait de couleur un peu moins large, ce qui donne une voie avec un bord noir. Comme la couleur est rendu après le bord, dans le premier cas elle superpose le bord de la voie d'à côté. Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Bon, je n'avais regardé que le premier exemple. Avec les autres, c'est clair que mon explication est à côté de la plaque. Sorry. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
On 12 mars 2013, at 09:14, Christian Quest cqu...@openstreetmap.fr wrote: Le rendu ne fait que transcrire les données qui à mon avis exagèrent l'angle dans le cas que tu indiques... on a vraiment l'impression qu'il y a comme une chicane. Le problème c'est que le point de jonction est sensé être a l'endroit physique ou les voies se séparent ou se raccordent, idem pour une sortie d'autoroute par exemple ou ce point devrait être juste a l'endroit après lequel il n'est plus possible de prendre la bretelle (cf quelque part dans le wiki) alors que si on tagguait pour le rendu (ouch c'est mal ;-) on mettrait ces points beaucoup plus éloignés pour avoir une transition plus douce. Je pense que le raccord entre traits épais et fins risque d'être délicat, mais rien n'est impossible, c'est juste un peu plus compliqué à traiter pour que ça soit graphiquement propre. Oui c'est sur qu'une fois confronté a tous les cas possibles plus ou moins justes vis a vis de la réalité... Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
C'est un essai... un peu radical et pas très heureux. Il y a plein de problèmes: - les angles réels sont lissés (il ne faudrait lisser qu'en dessous d'une certaine flèche) - les textes ne sont pas positionnés sur les tracés lissés Ce lissage donne quand même de bons résultats sur les railway=rail et les highway=motorway ainsi que les junction=roundabout Le 12 mars 2013 09:48, Francescu GAROBY windu...@gmail.com a écrit : J'ai la même à Caen : http://tile.openstreetmap.fr/?zoom=19lat=49.18171lon=-0.37274layers=B0 Les arrondis ne se font que sur des angles qui ne sont pas à 90° ? C'est du moins ce que je déduis de mes premières recherches... De toute façon, il y aura toujours des virages (quelque soit l'angle) dont le tracé est vraiment un angle, et non pas une courbe. Comment faire la distinction ? Un tag de plus sur le(s) node(s) qui fait(font) l'angle (du genre smooth=yes/no) ?!? Francescu Le 12 mars 2013 09:30, Simon Miniou simon.min...@gmail.com a écrit : Bonjour tout le monde, Sympa ce rendu ; merci. Concernant le lissage au zoom 19, ça donne un rendu très particulier : http://tile.openstreetmap.fr/?zoom=19lat=48.72586lon=4.58526layers=B0 vous en avez peut être parlé sur les tickets (j'ai un peu de mal à comprendre le fonctionnement), et c'est déjà en cours de traitement? Simon ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
De la lecture pour ces dernières soirées d'hiver... http://www.setra.equipement.gouv.fr/IMG/pdf/conception_geometrique_route.pdf Le 12 mars 2013 10:38, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : On 12 mars 2013, at 09:14, Christian Quest cqu...@openstreetmap.fr wrote: Le rendu ne fait que transcrire les données qui à mon avis exagèrent l'angle dans le cas que tu indiques... on a vraiment l'impression qu'il y a comme une chicane. Le problème c'est que le point de jonction est sensé être a l'endroit physique ou les voies se séparent ou se raccordent, idem pour une sortie d'autoroute par exemple ou ce point devrait être juste a l'endroit après lequel il n'est plus possible de prendre la bretelle (cf quelque part dans le wiki) alors que si on tagguait pour le rendu (ouch c'est mal ;-) on mettrait ces points beaucoup plus éloignés pour avoir une transition plus douce. Je pense que le raccord entre traits épais et fins risque d'être délicat, mais rien n'est impossible, c'est juste un peu plus compliqué à traiter pour que ça soit graphiquement propre. Oui c'est sur qu'une fois confronté a tous les cas possibles plus ou moins justes vis a vis de la réalité... Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 12 mars 2013 08:50, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : On 11 mars 2013, at 21:45, Philippe Verdy verd...@wanadoo.fr wrote: As-tu un exemple concret quelque part où tu voies réellement la boursouflure que tu décris ? A mon avis si tu la vois c'est que les voies après la séparation n'ont pas seulement la différence oneway=yes mais ont changé de nature (bref un problème de données existantes mais pas un problème du rendu actuel). Je parle de ce genre de choses : http://www.openstreetmap.org/browse/node/307405994 Ici par exemple l'emprise de la chaussée est a peu près équivalent avant et apres la séparation des deux voies mais le rendu exagère beaucoup la différence alors que si la largeur des voies à sens unique étaient divisisé par deux cela serait plus proche de la réalité Les voies séparées sont d'une part un peu trop écartées, d'autre part les angles de séparation sont exagérés dans la base elle-même. Ce n'est donc pas du tout un problème de rendu. Ceci, dit, comme les traits des voies à sens unique une fois écartés conservent leur largeur relative, ils sont effectivement trop larges sur leur longueur principale alors qu'il y a deux fois moins de files (il n'y a plus que les files dans un seul sens, les voies à gauche ont disparu, et l'axe unidirecttionnel au lieu d'être au centre de la chaussée unique se déportent, dans l'angle de raccordement, normalement progressivement du côté gauche vers le nouvel axe central unidirectionnel). Cependant pour un raccordement correct au point de jonction les axes se rejoignent et la largeur totale doit être rétablie progressivement au moins sur le dernier segment (ou sur une longueur depuis le point de jonction, correspondant à la largeur totale de la chaussée mesurée au point de jonction). L'algorithme de rendu qui utilise un simple buffer de largeur unique pour chaque segment ne sait pas faire ce changement progressivement pour non pas tailler un barreau rectangulaire, mais tronçon pyramidal. Le disque dessiné centré au point de jonction doit, lui, avoir un rayon correspondant à la largeur totale aux points de jonction, afin que tous les barreaux des buffers restent à peu près tangents (ce qui ne serait pas possible si la route changeait brutalement de largeur. En général quand des voies se séparent, il y a une zone sans terre plein et avec des zébrures au sol : le triangle de jonction devrait aller jusqu'à l'extrémité de cette zone pour faire un raccordement correct. Dans ce cas, il n'y a plus aucune boursouflure et le rendu reste correct, même avec le rendu actuel qui n'utilise que des barreaux rectangulaires (et non des tronçons pyramidaux comme cela devrait se faire pour avoir un ajustement progressif de la largeur de chaussée sur le premier segment après la séparation des voies). En améliorant la précision du tracé des axes dans OSM, on évite pratiquement entièrement ce problème de bousouflure excessive (mais pas complètement cependant car les routes conservent un rendu avec une largeur fixe quelque soit le nombre de files/lanes, estimées à 3 mètres chacune en largeur, ou même si on a indiqué la largeur totale des files (y compris les files latérales pour les bus, et la piste cyclable éventuelle qu'on peut estimer à 2 mètres, si elle est taguée sur la même voie et pas tracée à côté, ce qui devrait être le cas si elle est aussi séparée ou passe sur le trottoir). Mais dans ton exemple, le nombre de files n'est pas indiqué, il n'y a pas moyen d'estimer la largeur totale sans erreur. On pourrait cependant estimer par défaut une chaussée à 7 mètres si elles est bidirectionnelle, ou 3,50 mètres si elle est unidirectionnelle (en considérant qu'il n'y a alors qu'une seule file dans une direction donnée, plus environ 0,50m pour les bas-côtés. Pour les autoroutes c'est un peu différent : il y a aussi la bande d'arrêt d'urgence (qui disparaît et se transforme parfois en voie de sortie ou d'accélération près des échangeurs. Tout cela doit se réfléchir et peut faire l'objet d'ajustements géométriques sur une bonne estimation proche de la réalité. Mais on peut grandement améliorer déjà le rendu en traçant correctement les axes des routes avec plus de précision. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 12 mars 2013 10:09, Vincent Pottier vpott...@gmail.com a écrit : Étrange là aussi : http://tile.openstreetmap.fr/?zoom=19lat=46.36865lon=5.95777layers=B0 Double rendu du chemin. On dirait que c'est fait exprès pour les tests afin de comparer les tracés lissés avec les tracés non lissés, ou pour signaler les endroits où les courbures génèrent de trop gros écarts avec le tracé polygonal (ce qui suggèrerait qu'il manque des noeuds dans le polygone pour que les angles restent quasi-plats, au moins supérieurs à 150°, autrement dit moins de 30 degrés de déviation). Cela peut aussi être fait temporairement pour ajuster les paramètres de lissage (si c'est un lissage de Bézier, il est quadratique ou cubique ? Autrement dit, le calcul des tangentes estimées à chaque noeud du polygone initial génére-t-il un ou deux noeuds de contrôle supplémentaires entre les noeuds initiaux, permettant de finaliser la courbe avec une Bézier, simple à calculer récursivement jusqu'à obtenir des angles plats de plus de 175 degrés ? si c'est une cubique, la position des noeuds de contrôle ajoutés de part et d'autre du noeud initial n'est pas nécessairement la meilleure avec une simple partition en 3, il y a un taux à ajuster ; avec une quadratique on n'a pas le choix, le noeud de contrôle est à l'intersection des tangeantes, mais risque fort de trop déborder de la route en accentuant trop les angles vers l'extérieur du virage) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
On 12 mars 2013, at 10:38, Christian Quest cqu...@openstreetmap.fr wrote: C'est un essai... un peu radical et pas très heureux. Il y a plein de problèmes: - les angles réels sont lissés (il ne faudrait lisser qu'en dessous d'une certaine flèche) - les textes ne sont pas positionnés sur les tracés lissés Est-ce qu'il n'est pas possible de limiter l'action des courbes de bézier (bspline,... ou ce qui est utilisé ici) autour d'un angle pour modifier la route que très localement ce qui permettrait par exemple d'avoir des angle a 90° qui le resterait globalement mais dont seulement l'angle serait raboté ? Ce lissage donne quand même de bons résultats sur les railway=rail et les highway=motorway ainsi que les junction=roundabout ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Pour le rendu (propre) des lanes=*, c'est pas gagné ! Comme je m'y attendais, les raccords sont très moches et ce n'est même pas lié à un éventuel décalage avec les oneway... Juste un essai: http://wiki.openstreetmap.org/w/images/1/1b/Test-highway-lanes.png ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Ha tient j'habitais juste à coté avant 95 ;-) Pour le rendu, ça doit être très complexe mais il faudrait qu'à la jonction les voies en sens unique soient légèrement décalé… mais je présume que tu a déjà faire la même réflexion dans ton coin. Le 12 mars 2013 12:30, Christian Quest cqu...@openstreetmap.fr a écrit : Pour le rendu (propre) des lanes=*, c'est pas gagné ! Comme je m'y attendais, les raccords sont très moches et ce n'est même pas lié à un éventuel décalage avec les oneway... Juste un essai: http://wiki.openstreetmap.org/w/images/1/1b/Test-highway-lanes.png ___ 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] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
On 12 mars 2013, at 13:15, Jo. perche...@gmail.com wrote: Pour le rendu, ça doit être très complexe mais il faudrait qu'à la jonction les voies en sens unique soient légèrement décalé… mais je présume que tu a déjà faire la même réflexion dans ton coin. C'est pas si mal pour un premier essai et le décalage de la source des voies en sens unique comme dit plus haut pourrait bien aider mais cela doit surement être un peu complexe à traiter en SQL... Ensuite il y a le probleme du rendu des transitions, des line cap qui se voient trop... peut etre qu'il est possible d'utiliser un bout carré et coller par dessus un trapèze en SVG ? Le 12 mars 2013 12:30, Christian Quest cqu...@openstreetmap.fr a écrit : Pour le rendu (propre) des lanes=*, c'est pas gagné ! Comme je m'y attendais, les raccords sont très moches et ce n'est même pas lié à un éventuel décalage avec les oneway... Juste un essai: http://wiki.openstreetmap.org/w/images/1/1b/Test-highway-lanes.png ___ 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] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Justement je viens de voir ce style pour JOSM : http://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes qui vient de sortir et qui permet de visualiser dans l'éditeur tous les tags liés aux lanes, etc... L'exemple donné est un peu étrange, notamment la voie Roma A1 qui part à angle droit vers le bas... On 12 mars 2013, at 12:30, Christian Quest cqu...@openstreetmap.fr wrote: Pour le rendu (propre) des lanes=*, c'est pas gagné ! Comme je m'y attendais, les raccords sont très moches et ce n'est même pas lié à un éventuel décalage avec les oneway... Juste un essai: http://wiki.openstreetmap.org/w/images/1/1b/Test-highway-lanes.png ___ 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] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 12 mars 2013 12:30, Christian Quest cqu...@openstreetmap.fr a écrit : Pour le rendu (propre) des lanes=*, c'est pas gagné ! Comme je m'y attendais, les raccords sont très moches et ce n'est même pas lié à un éventuel décalage avec les oneway... Juste un essai: http://wiki.openstreetmap.org/w/images/1/1b/Test-highway-lanes.png Il suffit de voir comment l'autoroute (dessinée plus large) se raccorde à son extrémité aux autres voies primary, pour démontrer ce que j'expliquais plus haut : Il ne suffit pas simplement de diviser des voies en sens unique en divisant leur largeur par deux, on voit parfaitement que cela fait un goulot d'étranglement montrant le disque fixé à l'extrémité. Bref ma solution plus haut utilisant des trapèzes (troncs pyramidaux) et la seule qui convienne (on laisse le disque s'afficher uniquement sur les extrémités des chemins, et on ne verra l'arrondi de ce disque QUE si les voies raccordées à l'extrémité changent de couleurs à cause d'un changement de nature (ex. motorway primary). Dans l'idéal, si on devait correctement représenter la géométrie des routes, il faudrait que l'on trace l'axe central des routes à double sens, mais le côté gauche des voies en sens unique (du côté du terre-plain central). Mais toutes les rues à sens unique des villes seraient alors impactées. Une solution serait de renseigner avec un tag sur le way ce qu'on a tracé : par défaut c'est l'axe central, mais on pourrait alors indiquer que c'est le côté gauche, ou droite, avec un tag comme: highway:axis = lanes:left (cas le plus courant des sens-uniques en France, y compris les giratoires : bordure de la chaussée roulante à gauche, hors trottoirs et stationnements) highway:axis = lanes:right (cas le plus courant des sens-uniques au Royaume-Uni, y compris les giratoires : bordure de la chaussée roulante à droite, hors trottoirs et stationnements) highway:axis = lanes:center (valeur par défaut pour toutes les routes à double sens, et celles en sens unique dont on a tracé l'axe central) (il pourrait y avoir d'autres valeurs pour se positionner par rapport à d'autres objets que les lanes. Sinon on peut aussi enlever le préfixe lanes: Ce qui permettrait alors au moteur de rendu de savoir de quel côté étendre la largeur du buffer généré pour remplir la surface de la chaussée ou pour positionner les traits latéraux marquant les bordures de ponts. Si on voulait aller au delà, il faudrait tracer les polygones des chaussées comme on le fait pour les riverbanks des fleuves ou rivières, du moins ceux plus larges que 5 à 10 mètres environ, ce qui est aussi la largeur courante des routes et des rues). Mais cela demandera un travail énorme et on n'est pas encore prêt à faire ça (ce sera peut-être envisagé dans quelques années). Si cela se faisait, on commencerait d'abord par les autoroutes, voies express et boulevards urbains avec plus de 2 files roulantes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Pour un raccord propre, un trapèze SVG superposé côté étroit pourrait faire l'affaire... Il va falloir faire chauffer un peu postgis, mais ça ressemble au problème des passages piétons (retrouver l'orientation). En attendant, j'ai nettoyé un peu les routes du zoom 19 car il y avait des trucs pas clairs. Si vous avez des endroits bien complexes, n'hésitez pas à fournir un permalien ! Dans le genre, il y a ce pont: http://tile.openstreetmap.fr/?zoom=19lat=48.8303lon=2.49302layers=B0 un casse tête à mapper et aussi pour y circuler ;) Sinon... petite amélioration sur les passages piétons, ceux indiqués avec crossing=* (par exemple sur un feu de circulation) sont maintenant visibles. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Bonjour,
Le 11/03/2013 13:10, Christian Quest a écrit :
Le style est en place:
http://tile.openstreetmap.fr/?zoom=19lat=44.13525lon=4.8059layers=B0
Vous pouvez voir ce que ça donne sur des cas tordus et signaler les
problèmes via TRAC.
Comment ça marche ?
Requête SQL:
(select osm_id, ST_GeometryN(st_union(way),1) as way,
max(angle)-min(angle) as angle_diff, avg(angle) as angle from (select
p.osm_id, p.way as way,
cast(90+degrees(ST_Azimuth(st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),0),st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),1))) as integer) % 180 as angle from planet_osm_point p join
planet_osm_line h on (st_intersects(p.way,h.way) and h.highway is not
null and h.highway not in
('footway','cycleway','path','pedestrian','steps','service')) where
p.highway='crossing' and p.way !bbox!) as crossing group by osm_id
) as highway_crossings
Petit retour à hier : j'ai déposé par ici [1] ma manière de faire de
points orientés pour supporter un symbole avec rotation. Tu as du tout
spatial en une requête, j'ai du tout relationnel en plusieurs requêtes,
comme quoi :-)
Une question sur ta requête : comment gères-tu (ou pas) les mises à jour
en continu ? Est-ce que le zoom 19 permet, en opérant sur un volume de
données minuscule, de jouer la requête à chaque demande de tuile ?
J'avais éludé le problème de mon côté, fabriquant en une fois pour un
territoire assez large (Clermont-Fd), ce qui permet de s'asseoir sur les
performances :-(
vincent
[1] : https://github.com/vdct/Passages_pietons/blob/master/crossing.sql
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 12 mars 2013 21:13, Vincent de Chateau-Thierry v...@laposte.net a écrit :
Bonjour,
Le 11/03/2013 13:10, Christian Quest a écrit :
Le style est en place:
http://tile.openstreetmap.fr/?zoom=19lat=44.13525lon=4.8059layers=B0
Vous pouvez voir ce que ça donne sur des cas tordus et signaler les
problèmes via TRAC.
Comment ça marche ?
Requête SQL:
(select osm_id, ST_GeometryN(st_union(way),1) as way,
max(angle)-min(angle) as angle_diff, avg(angle) as angle from (select
p.osm_id, p.way as way,
cast(90+degrees(ST_Azimuth(st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),0),st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),1))) as integer) % 180 as angle from planet_osm_point p join
planet_osm_line h on (st_intersects(p.way,h.way) and h.highway is not
null and h.highway not in
('footway','cycleway','path','pedestrian','steps','service')) where
p.highway='crossing' and p.way !bbox!) as crossing group by osm_id
) as highway_crossings
Petit retour à hier : j'ai déposé par ici [1] ma manière de faire de points
orientés pour supporter un symbole avec rotation. Tu as du tout spatial en
une requête, j'ai du tout relationnel en plusieurs requêtes, comme quoi :-)
Une question sur ta requête : comment gères-tu (ou pas) les mises à jour en
continu ? Est-ce que le zoom 19 permet, en opérant sur un volume de données
minuscule, de jouer la requête à chaque demande de tuile ? J'avais éludé le
problème de mon côté, fabriquant en une fois pour un territoire assez large
(Clermont-Fd), ce qui permet de s'asseoir sur les performances :-(
vincent
[1] : https://github.com/vdct/Passages_pietons/blob/master/crossing.sql
Elle est mignonne ta requête !
Vu la bbox assez petite lors du rendu d'une metatile (2048x2048
pixels, ça doit faire de l'ordre du km2 je pense), c'est rapide (et
merci aussi le SSD). J'ai essayé en zoom 18, donc 4 fois plus grand et
ça va aussi.
Moi aussi j'hésite entre relationnel et spatial, mais finalement
postgis simplifie beaucoup les choses et ça s'est terminé en spatial.
--
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Champagne ! J'ai eu ma première étoile de git grâce à Jocelyn et ybon (utile par ces temps de neige). Et voilà ce que ça donne: https://github.com/cquest/osmfr-cartocss -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 12 mars 2013 21:13, Vincent de Chateau-Thierry v...@laposte.net a écrit : Une question sur ta requête : comment gères-tu (ou pas) les mises à jour en continu ? Est-ce que le zoom 19 permet, en opérant sur un volume de données minuscule, de jouer la requête à chaque demande de tuile ? J'avais éludé le problème de mon côté, fabriquant en une fois pour un territoire assez large (Clermont-Fd), ce qui permet de s'asseoir sur les performances :-( La requete est appelée lors du rendu, mais il n'y a pas rendu à chaque demande d'un client web. C'est mod_tile qui gère un cache de tuiles. Si osmfr utilise l'install standard, il y a un pont entre osmosis et mod_tile. Osmosis traite les diff en mettant à jour la base, mais fait également expirer les tuiles concernées dans le cache mod_tile. Si ces tuiles sont demandée par un client web, alors seulement elles sont alors rendues à nouveau avec les nouvelles données. Sur les dates d'expiration il y a également des raffinements en fonction du zoom de la tuile, mais ça me dépasse. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Cool !!! Bon, attends-toi à te faire bombarder de pull-requests : j'ai bien envie de personnaliser les logos pour les transports en commun de l'agglomération caennaise + quelques autres petites idées :-) Francescu Le 12 mars 2013 21:50, Christian Quest cqu...@openstreetmap.fr a écrit : Champagne ! J'ai eu ma première étoile de git grâce à Jocelyn et ybon (utile par ces temps de neige). Et voilà ce que ça donne: https://github.com/cquest/osmfr-cartocss -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Dans le genre plat de spaghetti, sur Lyon on a ça: http://tile.openstreetmap.fr/?zoom=17lat=45.77177lon=4.78927layers=B0 c'est rendu plutôt bien en fait ! un détail quand même: aux entrées/sorties de tunnel, la réalité correspondrait plus à un bout de ligne droit que arrondi ... chose que l'on retrouve également ici: http://tile.openstreetmap.fr/?zoom=18lat=45.75133lon=4.82329layers=B0 autre détail en regardant de plus près: la gestion des embranchements dans le cas de voies de niveau hiérarchique différent. ex ici (c’est aussi un peu visible sur les liens précédents): http://tile.openstreetmap.fr/?zoom=17lat=45.78947lon=4.86672layers=B0 au nord-est, le rond-point est coupé par 2 voies d'un niveau différents. au sud-ouest, les embranchements du périph recouvrent complétement la route normale. Dans l'idéal, il faudrait que les embranchements soient rendus en premier, puis les routes dont l'axe principal est rectiligne ;) ... mais bon, le requête sql ne doit pas être si simple ! Sylvain Le 12 mars 2013 21:55, Francescu GAROBY windu...@gmail.com a écrit : Cool !!! Bon, attends-toi à te faire bombarder de pull-requests : j'ai bien envie de personnaliser les logos pour les transports en commun de l'agglomération caennaise + quelques autres petites idées :-) Francescu Le 12 mars 2013 21:50, Christian Quest cqu...@openstreetmap.fr a écrit : Champagne ! J'ai eu ma première étoile de git grâce à Jocelyn et ybon (utile par ces temps de neige). Et voilà ce que ça donne: https://github.com/cquest/osmfr-cartocss -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ 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] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Première tentative de rendu des passages piétons en zoom 19... https://twitter.com/cq94/status/311052215412461568/photo/1 Qu'en pensez-vous ? C'est pas trivial... pour l'instant un seul cas de géré, le noeud highway_crossing sur un highway, mais pas à ses extrémités... y'a encore du boulot ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Bonjour, De : Christian Quest Première tentative de rendu des passages piétons en zoom 19... https://twitter.com/cq94/status/311052215412461568/photo/1 Qu'en pensez-vous ? Du bien :-) Et le z19 est vraiment pertinent pour ce genre d'info. C'est pas trivial... pour l'instant un seul cas de géré, le noeud highway_crossing sur un highway, mais pas à ses extrémités... y'a encore du boulot ! Que le passage piéton soit en extrémité ou pas ne change rien, si ? Ce qui compte en revanche c'est le nombre de ways convergeant sur le node : au delà de 2 il est compliqué de déterminer un angle pour le picto. J'avais fait une tentative en json [1] avec rendu par OpenLayers, mais ça n'était pas satisfaisant. En tout cas sans faire du rendu fr un inventaire à la Prevert, je trouve tout à fait sympathique de pouvoir illustrer ce niveau de détail, dans lequel figurent aussi par exemple les bornes à incendie, les bancs publics, etc. À ce niveau de zoom, on a de la place pour ça :-) vincent http://osm.vdct.free.fr/pp/index.html (limité à Clermont-Ferrand, avec des données assez anciennes) Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 11:46, Vincent de Chateau-Thierry v...@laposte.net a écrit :
Bonjour,
De : Christian Quest
Première tentative de rendu des passages piétons en zoom 19...
https://twitter.com/cq94/status/311052215412461568/photo/1
Qu'en pensez-vous ?
Du bien :-)
Et le z19 est vraiment pertinent pour ce genre d'info.
C'est pas trivial... pour l'instant un seul cas de géré, le noeud
highway_crossing sur un highway, mais pas à ses extrémités... y'a
encore du boulot !
Que le passage piéton soit en extrémité ou pas ne change rien, si ? Ce qui
compte en
revanche c'est le nombre de ways convergeant sur le node : au delà de 2 il
est compliqué
de déterminer un angle pour le picto. J'avais fait une tentative en json [1]
avec rendu
par OpenLayers, mais ça n'était pas satisfaisant.
Si il est en extrémité de 2 ways, il faut calculer l'angle de chaque
way, puis faire la moyenne et voir si on reste dans un fourchette
donnée... c'est bientôt fait ;)
Tu as aussi le passage sur un branche en Y... et les croisements en X
là je pense mettre une icône.
En tout cas sans faire du rendu fr un inventaire à la Prevert, je trouve
tout à fait
sympathique de pouvoir illustrer ce niveau de détail, dans lequel figurent
aussi par
exemple les bornes à incendie, les bancs publics, etc. À ce niveau de zoom,
on a de la
place pour ça :-)
Entièrement d'accord, ce niveau de zoom permet de rendre visible le
mobilier urbain, et donc de montrer les détails qui peuvent être
présents (par endroit) dans nos data et c'est important de montrer ces
détails tout en conservant un rendu pas trop chargé... tout un
équilibre à trouver !
Pour info, voici la requête qui devrait me permettre de gérer les
passages en Y et X:
select osm_id, ST_GeometryN(st_union(way),1), max(angle)-min(angle) as
angle_diff, avg(angle) as angle from (select p.osm_id, p.way as way,
cast(90+degrees(ST_Azimuth(st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),0),st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),1))) as integer) % 180 as angle from planet_osm_point p join
planet_osm_line h on (st_intersects(p.way,h.way) and h.highway is not
null and h.highway not in ('footway','cycleway','path','pedestrian'))
where p.highway='crossing' and p.way !bbox! as crossing group by
osm_id
Le principe:
- récupérer les nœuds highway=crossing
- retrouver les highway auxquelles ils appartiennent (ST_Intersects)
- calculer les directions via l'intersection du way avec un petit
buffer autour du noeud (st_buffer + st_intersection +
st_line_interpolate_point + st_azimuth)
- appliquer une rotation de 90° et réduire ça à un intervalle 0-180°
(pour gérer les sens opposés qui au final on le même rendu)
- pour terminer, regrouper tout ça par passage piéton en sortant
l'angle moyen + l'écart maxi des angles des way qui aboutissent sur le
passage piéton
Ne reste plus qu'à la feuille de style de prendre en compte les petits
écarts pour rendre les zebra, et les grands écarts pour mettre une
icône...
Le rendu carto c'est un petit peu plus que du design graphique ;)
--
Christian Quest - OpenStreetMap France
Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Chez les utilisateurs de Maperitive, quelqu'un sait si on a l'option d'orienter un shape/icon ponctuel sur une ligne ? Perso, je n'ai pas trouvé, mais les nested query le rendront peut-être possible bientôt… Et chez Tilemill, tu nous donnerais le code pour cette orientation, Christian ? Je n'avais pas encore cherché dans cette direction… Aller, et pour les présents à la démo Maperitive au SotM-fr, chose promise, ça avance, on approche des 2000 lignes de feuille de style… Un aperçu : http://jb.tradfrance.com/demo.png . Mais on en reparlera plus tard… JB. Le 11.03.2013 10:58, Christian Quest a écrit : Première tentative de rendu des passages piétons en zoom 19... https://twitter.com/cq94/status/311052215412461568/photo/1 [1] Qu'en pensez-vous ? C'est pas trivial... pour l'instant un seul cas de géré, le noeud highway_crossing sur un highway, mais pas à ses extrémités... y'a encore du boulot ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr [2] Links: -- [1] https://twitter.com/cq94/status/311052215412461568/photo/1 [2] 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] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 12:15, Christian Quest cqu...@openstreetmap.fr a écrit : Tu as aussi le passage sur un branche en Y... et les croisements en X là je pense mettre une icône. La passages piétons qui sont sur une intersection de voies sont plutôt à signaler sur Osmose car la situation semble trop dangereuse pour les piétons pour qu'on leur permette de traverser en devant regarder à 360 degrés. La cause peut être ne fait que les voies qui se croisent en sens inverse ne sont en fait pas sur la même chaussée et qu'il y a un espace central pour piétons, ou l'absence d'un rond-point à dessiner (quand les piétons peuvent circuler sur le rond-point central). Même pour une traversée piéton unique traversant deux voies arrivant ou sortant quasi-parallèlement dans le carrefour , celles-ci ne devraient pas se rejoindre sur le passage clouté lui-même mais au point triple où elle rencontrent la 3e ou 4e voie. L'autre cause est qu'on a placé de façon erroné le passage piéton au milieu du carrefour au lieu de le mettre avant ou après ce carrefour. Bien sûr ne pas dessiner les zébrures, éventuellement afficher l'icône (mais à mon avis c'est même inutile dans ce cas-là puisqu'elle est très certainement mal placée). Un passage piéton est donc normalement connecté à uniquement deux segments des voies pour véhicules, et à 2 segments du chemin piéton (peut être 3 ? il me semble que non, les chemins piétons eux non plus devrait pas se croiser sur la chaussée elle-même). Cela pourrait faire l'objet d'une analyse du positionnement correct de ces passages piétons (il devrait y avoir partout 4 segments connectés au noeud, 2 routiers, 2 uniquement pour piétons). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 12:44, Philippe Verdy verd...@wanadoo.fr a écrit : Cela pourrait faire l'objet d'une analyse du positionnement correct de ces passages piétons (il devrait y avoir partout 4 segments connectés au noeud, 2 routiers, 2 uniquement pour piétons). J'oubliais: le passage piétons peut être marqué sans pour autant qu'il soit connecté à un chemin piéton qui le traverse (parce qu'on ne trace généralement pas séparément de la rue, le/les trottoirs qui la longent d'un côté ou l'autre). Donc pas plus de 4 segments connectés au noeud du passage piétons (donc toujours 2, 3 ou 4 segments connectés, et toujours 2 pour véhicules) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 10:58, Christian Quest cqu...@openstreetmap.fr a écrit : Première tentative de rendu des passages piétons en zoom 19... https://twitter.com/cq94/status/311052215412461568/photo/1 Qu'en pensez-vous ? C'est un travail magnifique et qui va nous être tellement utile. Juste que les passages piétons pourraient être un poil moins large. Cyrille C'est pas trivial... pour l'instant un seul cas de géré, le noeud highway_crossing sur un highway, mais pas à ses extrémités... y'a encore du boulot ! ___ 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
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 12:55, Cyrille Giquello cyrill...@gmail.com a écrit : Le 11 mars 2013 10:58, Christian Quest cqu...@openstreetmap.fr a écrit : Première tentative de rendu des passages piétons en zoom 19... https://twitter.com/cq94/status/311052215412461568/photo/1 Qu'en pensez-vous ? C'est pas mal ! Je vais creuser une solution sans image, adaptable aux cas tordus C'est un travail magnifique et qui va nous être tellement utile. Juste que les passages piétons pourraient être un poil moins large. +1 Je verrai bien 3 bandes seulement, centrées, et laissant apparaitre la couleur de la rue coté trottoir. La couleur est bien, par contre il semble qu'il y ait un petit trait noir autour de chaque bande dont on pourrait se passer Bruno, coupeur de cheveux en 360° ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
De : Christian Quest Première tentative de rendu des passages piétons en zoom 19... https://twitter.com/cq94/status/311052215412461568/photo/1 Qu'en pensez-vous ? Du bien :-) Et le z19 est vraiment pertinent pour ce genre d'info. Autre chose dans le même genre d'idée: quand des voies de service (réservées à certains véhicules : bus, trams) traversent une chaussée pour d'autres véhicules, on a un marquage au sol le plus souvent en damiers sur la zone d'intersection. De même on pourrait avoir au zoom 19 un marquage spécial des passages à niveau (sur les bas-côtés de la voie ferrée). En principe on devrait trouver assez souvent aussi l'emplacement des barrières de signalisation qui traversent la chaussée de chaque côté de la voie ferrée (mais pas immédiatement non plus sur la zone des bas-côtés de la voie ferrée, il peut y avoir assez souvent encore un espace de sécurité). Et un feu qui sert autant à la signalisation clignotante d'alerte, qu'en mode tricolore pour laissant traverser les piétons le long de la barrière, entre la barrière et les véhicules arrêtés, sur un trottoir parallèle à la voie mais hors des deux barrières). Certains passage à niveau pourraient éventuellement être assez étroits pour ne permettre leur traversée qu'en mode alterné, avec des feux tricolores de chaque côté. Tous les passages à niveau n'ont pas non plus nécessairement de barrières, juste un feu clignotant d'alerte (ceci inclue les feux signalant l'arrivée d'un tram, par exemple à Nantes). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le style est en place:
http://tile.openstreetmap.fr/?zoom=19lat=44.13525lon=4.8059layers=B0
Vous pouvez voir ce que ça donne sur des cas tordus et signaler les
problèmes via TRAC.
Comment ça marche ?
Requête SQL:
(select osm_id, ST_GeometryN(st_union(way),1) as way,
max(angle)-min(angle) as angle_diff, avg(angle) as angle from (select
p.osm_id, p.way as way,
cast(90+degrees(ST_Azimuth(st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),0),st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),1))) as integer) % 180 as angle from planet_osm_point p join
planet_osm_line h on (st_intersects(p.way,h.way) and h.highway is not
null and h.highway not in
('footway','cycleway','path','pedestrian','steps','service')) where
p.highway='crossing' and p.way !bbox!) as crossing group by osm_id
) as highway_crossings
Style cartocss:
#highway_crossings {
[zoom=19][angle_diff30] {
point-ignore-placement: true;
point-file: url('symbols/fr/crossing2.png');
point-transform: 'rotate([angle])';
}
[zoom=19][angle_diff=30] {
point-file: url('symbols/fr/crossing.png');
point-transform: 'scale(0.75)';
}
}
Donc... si l'angle des différents segments qui aboutissent sur un
highway_crossing ont plus de 30° d'écart, je met une icone de passage
piéton, sinon je met les bandes blanches correctement orientées (enfin
gris très clair).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
2013/3/11 Christian Quest cqu...@openstreetmap.fr:
Le style est en place:
http://tile.openstreetmap.fr/?zoom=19lat=44.13525lon=4.8059layers=B0
Vous en avez certainement parlé, mais j'ai du zapper un truc. Dans
l'exemple ci-dessus qu'elle est la différence entre l'icone bleue et
les bandes dessinées ?
Merci
C.
Vous pouvez voir ce que ça donne sur des cas tordus et signaler les
problèmes via TRAC.
Comment ça marche ?
Requête SQL:
(select osm_id, ST_GeometryN(st_union(way),1) as way,
max(angle)-min(angle) as angle_diff, avg(angle) as angle from (select
p.osm_id, p.way as way,
cast(90+degrees(ST_Azimuth(st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),0),st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),1))) as integer) % 180 as angle from planet_osm_point p join
planet_osm_line h on (st_intersects(p.way,h.way) and h.highway is not
null and h.highway not in
('footway','cycleway','path','pedestrian','steps','service')) where
p.highway='crossing' and p.way !bbox!) as crossing group by osm_id
) as highway_crossings
Style cartocss:
#highway_crossings {
[zoom=19][angle_diff30] {
point-ignore-placement: true;
point-file: url('symbols/fr/crossing2.png');
point-transform: 'rotate([angle])';
}
[zoom=19][angle_diff=30] {
point-file: url('symbols/fr/crossing.png');
point-transform: 'scale(0.75)';
}
}
Donc... si l'angle des différents segments qui aboutissent sur un
highway_crossing ont plus de 30° d'écart, je met une icone de passage
piéton, sinon je met les bandes blanches correctement orientées (enfin
gris très clair).
___
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
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Cool, je viens de tester sur une zone où j'ai ajouter les passage piéton au
abords du stade (gros mouvement de foule les jours de match) :
http://tile.openstreetmap.fr/?zoom=19lat=43.18267lon=3.01662layers=B0
Par contre, un peut plus étroit serait visuellement moins chargé, ça fait
un peut patté (hummm j'ai faim là)
Le 11 mars 2013 13:25, Cyrille Giquello cyrill...@gmail.com a écrit :
2013/3/11 Christian Quest cqu...@openstreetmap.fr:
Le style est en place:
http://tile.openstreetmap.fr/?zoom=19lat=44.13525lon=4.8059layers=B0
Vous en avez certainement parlé, mais j'ai du zapper un truc. Dans
l'exemple ci-dessus qu'elle est la différence entre l'icone bleue et
les bandes dessinées ?
Merci
C.
Vous pouvez voir ce que ça donne sur des cas tordus et signaler les
problèmes via TRAC.
Comment ça marche ?
Requête SQL:
(select osm_id, ST_GeometryN(st_union(way),1) as way,
max(angle)-min(angle) as angle_diff, avg(angle) as angle from (select
p.osm_id, p.way as way,
cast(90+degrees(ST_Azimuth(st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),0),st_line_interpolate_point(ST_Intersection(st_buffer(p.way,0.1),
h.way),1))) as integer) % 180 as angle from planet_osm_point p join
planet_osm_line h on (st_intersects(p.way,h.way) and h.highway is not
null and h.highway not in
('footway','cycleway','path','pedestrian','steps','service')) where
p.highway='crossing' and p.way !bbox!) as crossing group by osm_id
) as highway_crossings
Style cartocss:
#highway_crossings {
[zoom=19][angle_diff30] {
point-ignore-placement: true;
point-file: url('symbols/fr/crossing2.png');
point-transform: 'rotate([angle])';
}
[zoom=19][angle_diff=30] {
point-file: url('symbols/fr/crossing.png');
point-transform: 'scale(0.75)';
}
}
Donc... si l'angle des différents segments qui aboutissent sur un
highway_crossing ont plus de 30° d'écart, je met une icone de passage
piéton, sinon je met les bandes blanches correctement orientées (enfin
gris très clair).
___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
De : JB [mailto:jb...@mailoo.org] Envoyé : lundi 11 mars 2013 12:37 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !) … Aller, et pour les présents à la démo Maperitive au SotM-fr, chose promise, ça avance, on approche des 2000 lignes de feuille de style… Un aperçu : http://jb.tradfrance.com/demo.png . Mais on en reparlera plus tard… JB. Ça a vraiment de la gueule. En plus, c’est un joli coin ! Bravo les rendereurs… Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
J'ai écrit un petit billet de blog sur le site: http://openstreetmap.fr/mapnik-passages-pietons ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 13:03, Bruno Cortial bruno.cort...@laposte.net a écrit : Je verrai bien 3 bandes seulement, centrées, et laissant apparaitre la couleur de la rue coté trottoir. La couleur est bien, par contre il semble qu'il y ait un petit trait noir autour de chaque bande dont on pourrait se passer Si seules les bandes sont blanches, sans même aucun liseré fin de bordure autour des bandes, il y aura un problème pour les voir sur les voies de service, et les rues résidentielles qui sont déjà en blanc... En général les toutes et rues sont dans une couleur déjà assez claire, un liseré légèrement plus foncé que la bande elle-même peut aider à mieux les voir. Mais les bandes en blanc pourraient empêcher de lire correctement du texte en blanc (non ombré) qui viendrait se positionner par dessus (pas les noms de rue ni les numéros de maisons, qui sont en noir avec un ombrage blanc autour, mais certains autres textes sont parfois blancs, je ne me rappelle plus où, cela a peut-être changé dans cette version de Mapnik). La lisibilité des textes doit rester assurée et il faut bien un peu contraster les zébrures sur les différentes couleurs possibles de rues et routes (voire de voies ferrées pour les petits passages à niveau traversables uniquement par des piétons (sur une voie ferrée mineure sans passerelle, par exemple celles qu'on voit dans les zones portuaires et où les rares trains sont à vitesse très lente, mais où pourtant les véhicules peuvent être interdits pour éviter qu'ils stationnent n'importe où) Question : comment expliquer l'apparence de ceci: http://b.tile.openstreetmap.fr/osmfr/19/266541/192290.png (les angles des segments de route connectés sont dans les deux cas quasi plats, mais deux présentations sur cette même tuile). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Au fait les passage piétons ont ici l'apparence française la plus courante, mais par endroit ce sont des plots latéraux en métal, ou bien des mozaïques en damiers. Dans certains pays les bandes ne sont pas dans le sens de la chaussée mais obliques par rapport à elle. Dans certains endroits le passage piéton est marqué par des petites bandes de chaque côté du passage piéton,. Parfois c'est juste un changement de revêtement (complété aussi d'un dos d'âne à priori déjà marqué par un autre tag), par exemple des dalles claires (en ciment recouvert de petits cailloux pour ne pas glisser) couvrant toute la surface du passage piéton alors que le reste de la chaussée reste donc un revêtement plus classique en asphalte (on trouve ces passages piétons décorés par exemple quand c'est la traversée d'une rue piétonne très commerciale, ou près de certains établissements de prestige comme des casinos. Sur les terrains privés, il n'y a pas de règles (parkings de supermarchés par exemple). Enfin les bandes peuvent changer de couleur : on a des bandes jaunes pour les traversées provisoires pendant qu'un côté d'une rue est en travaux et ferme son trottoir. Ne pas oublier non plus les marquages au sol des traversées de voies bus, et les bandes vertes (parfois bleues) pour les traversées de pistes cyclables. Peut-être faut-il des tags spécifiques pour le type de marquage des passages piétons, et une règle ajoutée dans la relation applies_to qui fixe des tags par défaut applicables pour toute une région ou pour le pays entier (pour éviter d'avoir à rajouter des tags sur tous les passages piétons d'une région). 2013/3/11 Christian Quest cqu...@openstreetmap.fr: J'ai écrit un petit billet de blog sur le site: http://openstreetmap.fr/mapnik-passages-pietons ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 14:48, Philippe Verdy verd...@wanadoo.fr a écrit : Question : comment expliquer l'apparence de ceci: http://b.tile.openstreetmap.fr/osmfr/19/266541/192290.png (les angles des segments de route connectés sont dans les deux cas quasi plats, mais deux présentations sur cette même tuile). Dans mon PNG il n'y a pas de liseré, je pense que c'est un artifact de la rotation SVG. Je ne me suis pas trop focalisé sur le côté graphique, il fallait déjà que ça fonctionne côté requête SQL et style. Je pense que je vais refaire le tracé en SVG, ce qui donnera sûrement de meilleurs résultats sur les transformations SVG. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Voilà, maintenant c'est un SVG et c'est nettement plus propre avec la rotation. J'ai aussi réduit la largeur. N'oubliez pas de vider vos caches ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Puisque c'est du SVG maintenant, sans doûte les bandes peuvent être plus claires, car il y a moyen d'inclure un liseré de bordure dans un gris un peu plus foncé mais plus transparent que les bandes elles-mêmes (sont-elles semi-transparentes ou en couleur pleine alpha=100% ?), ce qui améliorerait leur visibilité sans compromettre la présence d'autre chose par dessus ni occuper trop de surface pleine sur la rue en dessous. Si un channel alpha n'est pas utilisé dans les couleurs de remplissage du SVG (alpha=100%), même une bordure pleine de 1/2 pixel de large (dans la taille de rendu du SVG final) suffirait à le rendre semi transparent sur le rendu final, et s'assurer que quelque soit la couleur de fond de la rue, l'icône restera bien visible. Le 11 mars 2013 15:58, Christian Quest cqu...@openstreetmap.fr a écrit : Voilà, maintenant c'est un SVG et c'est nettement plus propre avec la rotation. J'ai aussi réduit la largeur. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Récemment je me suis demandé pourquoi aucun rendu courant ne traite les voies en sens unique en les traçants deux fois moins larges par défauts que les voies en double sens car le rendu est souvent assez moche quand par exemple une route se sépare en 2 voies pour chaque sens sur une petite distance pour ensuite re-fusionner, ça fait des boursouflures pas belles et qui ne représentent pas la situation réelle. La largeur de la route pourrait aussi tenir compte de l'attribut lanes. C'est sur que dans un premier temps certains endroits seraient rendu bizarrement si on a triché sur la position des voies mais cela permettrait de corriger. C'est possible sur le super rendu FR ? Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 16:23, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Récemment je me suis demandé pourquoi aucun rendu courant ne traite les voies en sens unique en les traçants deux fois moins larges par défauts que les voies en double sens car le rendu est souvent assez moche quand par exemple une route se sépare en 2 voies pour chaque sens sur une petite distance pour ensuite re-fusionner, ça fait des boursouflures pas belles et qui ne représentent pas la situation réelle. La largeur de la route pourrait aussi tenir compte de l'attribut lanes. C'est sur que dans un premier temps certains endroits seraient rendu bizarrement si on a triché sur la position des voies mais cela permettrait de corriger. C'est possible sur le super rendu FR ? C'est en projet... gérer lanes et width et effectivement oneway pourrait aussi réduire un peu la largeur des voies. Je pense que ça vaudrait le coup à partir du zoom 18, voire éventuellement 17 (à tester). -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le rendu me semble très bien fichu :o) mais j'ai quelques petite question. Un dessin avec les bandes blanche mais sur un fond rectangle noir ce ne serait pas plus explicite? ça complique la lecture d'autres indication? Quelques piste d'amélioration future : marquer les passages surbaissés avec un petit trapèze aux extrémités du passage plutôt qu'un rectangle par exemple. Le 11 mars 2013 16:35, Christian Quest cqu...@openstreetmap.fr a écrit : Le 11 mars 2013 16:23, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : C'est en projet... gérer lanes et width et effectivement oneway pourrait aussi réduire un peu la largeur des voies. Je pense que ça vaudrait le coup à partir du zoom 18, voire éventuellement 17 (à tester). -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ 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] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 16:23, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Récemment je me suis demandé pourquoi aucun rendu courant ne traite les voies en sens unique en les traçants deux fois moins larges par défauts que les voies en double sens car le rendu est souvent assez moche quand par exemple une route se sépare en 2 voies pour chaque sens sur une petite distance pour ensuite re-fusionner, ça fait des boursouflures pas belles et qui ne représentent pas la situation réelle. La largeur de la route pourrait aussi tenir compte de l'attribut lanes. Les boursouflures dont tu parles ne sont pas plus épaisses que lécartement fait entre les voies. Mais si ta solution était adoptée, juste à l'endroit de la séparation la route aurait tout à coup un rétrécissement de moitié de sa largeur... ce qui serait encore pire ! Seule solution : conserver la largeur à droite de chaque voie en sens unique. Mais on peut réduire en revanche la largeur à gauche, afin de rendre mieux visible la séparation des deux sens (par exemple réduire la largeur à gauche (du côté de la séparation centrale) de moitié, ce qui collera bien mieux à la réalité et montrera que cette prétendue boursouflure a en fait bel et bien pour cause une séparation qui est cette fois bien visible. A moins qu'on ait une indication du nombre de voies (lanes) ou de la largeur, avant et après la séparation/jonction des deux sens car dans ce cas il n'est plus nécessaire d'estimer l'emprise de buffer à garder au centre sur les voies à sens unique. Mais même dans ce cas, il n'y a pas de raison de réduire la largeur à droite du tracé (ce changement de largeur du buffer à droite de chaque sens ne peut se faire que de façon progressive entre deux noeuds où la largeur des voies est précisée) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 à 17:12, Philippe Verdy verd...@wanadoo.fr a écrit : Le 11 mars 2013 16:23, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Récemment je me suis demandé pourquoi aucun rendu courant ne traite les voies en sens unique en les traçants deux fois moins larges par défauts que les voies en double sens car le rendu est souvent assez moche quand par exemple une route se sépare en 2 voies pour chaque sens sur une petite distance pour ensuite re-fusionner, ça fait des boursouflures pas belles et qui ne représentent pas la situation réelle. La largeur de la route pourrait aussi tenir compte de l'attribut lanes. Les boursouflures dont tu parles ne sont pas plus épaisses que lécartement fait entre les voies. Mais si ta solution était adoptée, juste à l'endroit de la séparation la route aurait tout à coup un rétrécissement de moitié de sa largeur... ce qui serait encore pire ! Mais non pas du tout car chaque voie à sens unique devrait être axé sur le prolongement de la voie correspondante issue de la route à double sens et de largeur 1/2 (ou un poil moins). La transition entre les deux devrait être absorbée par l'arrondi au bout du segment en double sens. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 18:14, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Mais non pas du tout car chaque voie à sens unique devrait être axé sur le prolongement de la voie correspondante issue de la route à double sens et de largeur 1/2 (ou un poil moins). La transition entre les deux devrait être absorbée par l'arrondi au bout du segment en double sens. Je pense qu'il va y avoir quelques surprises et trucs pas très jolis. Avec les passages piéton, c'est un peu ce que j'ai découvert petit à petit comme l'intersection de voies routières et de chemins piéton qu'il ne faut pas prendre en compte pour l'orientation des zebra. Il faut essayer et ajuster en fonction des problèmes rencontrés, mode essai/erreur ;) -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 11 mars 2013 18:14, Vladimir Vyskocil vladimir.vysko...@gmail.com a écrit : Mais non pas du tout car chaque voie à sens unique devrait être axé sur le prolongement de la voie correspondante issue de la route à double sens Pas forcément. Ce ne serait le cas si la largeur totale des deux chaussées ne changeait pas du tout. Hors si les voies se séparent, c'est (le plus souvent, sauf cas d'une voie centrale condamnée par des zébrures et plots) que ce n'est plus la même chaussée et qu'un terre-plain ou une barrière vient s'intercaler, il ajoute un peu de largeur à la route. et de largeur 1/2 (ou un poil moins). La transition entre les deux devrait être absorbée par l'arrondi au bout du segment en double sens. l'arrondi ne sera pas suffisant. c'est justement au bout de cet arrondi qu''on verra le rétrécissement en goulot de là où partent/arrivent les deux voies à sens unique, puisque tu les as réduites de moitié arbitrairement. Regarde se qui se passe plutôt du côté droit de la route, sens par sens : le profil de la voie suit à peu près la même courbe lors de la séparation, et imagine que c'est la voie en double-sens qui est déjà coupée en deux moitiés mitoyennes bord à bord. le centre de la voie en double sens est alors le côté gauche de chaque moitié, et la largeur de ce bord central au bas-côté droit ne change pas, que ce soit avant ou après la séparation. Pourtant c'est l'axe de la voie en sens unique qui va se déporter vers la droite de façon linéaire mais pas brutalement à l'endroit de la séparation : c'est là avec ta solutions que tu verras apparaître le morceau d'arrondi rétrécissant temporairement la chaussée à droite pour former un goulot étroit d'où sortirait alors la voie en sens unique. Zoome déjà sur les endroits où ça se produit : la solution actuelle ne montre aucun goulot d'étranglement de la chaussée sur le côté droit. en sortie de la séparation As-tu un exemple concret quelque part où tu voies réellement la boursouflure que tu décris ? A mon avis si tu la vois c'est que les voies après la séparation n'ont pas seulement la différence oneway=yes mais ont changé de nature (bref un problème de données existantes mais pas un problème du rendu actuel). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 22/02/2013 16:02, ades_...@orange.fr a crit: , autant je coince sur la suppression des limites d'immeubles dans les vues rapproches. En gnral ces limitations d'origine cadastrales collent assez bien avec la ralit et c'est un bon indicateur de la morphologie des zones urbanises. +1 bonjour, carrment en ce qui concerne le zoom 18 et 17 et pas seulement pour reprer la 4me maison. Il s'agit l bien de lire une information morphologique importante qui en dit long culturellement. Du bati accol sur des parcelles en lanires n'a rien voir avec une grosse longre qui a subi des rallongements successifs. djo_man ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 22 février 2013 23:54, Vincent Pottier vpott...@gmail.com a écrit : Ouh, je sens l'embrouille... Le 22/02/2013 19:35, Philippe Verdy a écrit : Utiliser des polygones mitoyens. [...] - Justifié aussi par leur différences de hauteurs (qu'on peut ajouter facilement avec un tag ele=* unique sur le polygone) [...] tag ele=* pour hauteur du bâtiment ou altitude ? Je sais c'est ambigu, mais ma remarque était aussi valable avec le tag height=* Il y a d'autres tags encore pour la modélisation plus ou moins 3D des bâtiments, ou une description plus synthétique comme le nombre d'étages -- et ce n'est pas toujours évident de donner la hauteur d'un bâtiment construit en flanc de colline ou carrément adossé à une falaise ou le rez-de chaussée d'un côté est plusieurs étages au dessus du rez-de-chaussée de l'autre côté (un exemple fameux étant dans le centre-ville de Lisbonne avec son ascenseur historique passant d'une rue à l'autre avec aussi une passerelle passant en dessous d'une autre rue et d'un autre bâtiment, exemple compliqué encore par le fait que la base de cet ascenseur est en fait déjà sur une petite place en haut de quelques marches, mais sous cette place il s'agit aussi d'un étage de rez-de-chaussée entre deux bâtiments : où est le rez-de-chaussée dans tout ça ? Si on n'a que height=*, on ne s'en sort pas du tout, il ne reste que l'altitude absolue pour modéliser ça !). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Autant je suis ok pour la simplification du landuse pour les vues larges, autant je coince sur la suppression des limites d'immeubles dans les vues rapprochées. En général ces limitations d'origine cadastrales collent assez bien avec la réalité et c'est un bon indicateur de la morphologie des zones urbanisées. Et comment on fait pour repérer la 4e maison de la rue Bidule ? :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)
Le 22 février 2013 16:02, ades_...@orange.fr ades_...@orange.fr a écrit : Autant je suis ok pour la simplification du landuse pour les vues larges, autant je coince sur la suppression des limites d'immeubles dans les vues rapprochées. En général ces limitations d'origine cadastrales collent assez bien avec la réalité et c'est un bon indicateur de la morphologie des zones urbanisées. Et comment on fait pour repérer la 4e maison de la rue Bidule ? :-) Utiliser des polygones mitoyens. - Justifié par des numérotions différentes dans la rue pour les adresses (même si on peut aussi les mettre sur un noeud à part près de l'entrée ou sur la porte) - Justifié par des différences de constructions (si on veut taguer les matériaux visibles, notamment pour les immeubles vitrés, ou la couleur, deux éléments de repérage faciles depuis le terrain) - Justifié aussi par leur différences de hauteurs (qu'on peut ajouter facilement avec un tag ele=* unique sur le polygone) ou de pentes de toits (plus compliqué car cela demande une représentation 3D plus complète sur chaque noeud, et de superposer à la même lat/lon des noeuds diffférents mais de hauteur différente), comme le fait Google Map en vue rapprochée où il dessine la forme des bâtiments en pseudo-perspective (pas partout mais par exemple à Paris) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
