Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu "FR" (était: osm13 est opérationnel !)

[Stéphane MARTIN]

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 !)

[Cyrille Giquello]

Géniale cette visite guidée. Quelle bonne idée !


Le 25 avril 2013 15: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
>
> --
> 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 !)

[Christian Quest]

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 !)

[Tetsuo Shima]

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 !)

[Christian Quest]

Je n'ai quasiment pas touché ces niveaux de zoom... ça vaut un ticket ;)


Le 21 mars 2013 17:00, Stéphane MARTIN  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  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=8&lat=4.07937&lon=-54.35198&layers=B0
> http://tile.openstreetmap.fr/?zoom=5&lat=1.84678&lon=-49.9547&layers=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 !)

[Stéphane MARTIN]

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  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=8&lat=4.07937&lon=-54.35198&layers=B0
http://tile.openstreetmap.fr/?zoom=5&lat=1.84678&lon=-49.9547&layers=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 !)

[Christian Quest]

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  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 !)

[Stéphane MARTIN]

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 !)

[Bruno Cortial]

Le 18 mars 2013 12:04, Philippe Verdy  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 !)

[Philippe Verdy]

Le 18 mars 2013 11:29, Bruno Cortial  a écrit :
> Le 16 mars 2013 22:11, Ab_fab  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 !)

[Bruno Cortial]

Le 16 mars 2013 22:11, Ab_fab  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 !)

[Ab_fab]

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  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  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 
"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 !)

[Jean-Claude Repetto]

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 !)

[Christian Quest]

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  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 !)

[Jean-Claude Repetto]

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 !)

[Christian Quest]

Le 16 mars 2013 00:54, Jean-Claude Repetto  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 !)

[Jean-Claude Repetto]

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 !)

[Philippe Verdy]

Le 14 mars 2013 20:59, Francescu GAROBY  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 !)

[Christian Quest]

Le 14 mars 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
>


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 !)

[Vincent Pottier]

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 !)

[Francescu GAROBY]

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  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 !)

[Christian Quest]

Le 14 mars 2013 12:06, Pieren  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 !)

[Christian Quest]

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 !)

[Pieren]

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 !)

[Francescu GAROBY]

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  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.jpg
>
> Jean-Claude
>
>
>
> __**_
> 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 !)

[Jean-Claude Repetto]

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 !)

[CedricDV]

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  > 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  > 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
> 


___
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 !)

[Philippe Verdy]

Le 14 mars 2013 10:25, Jo.  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 !)

[Francescu GAROBY]

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  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  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 !)

[Jo.]

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  a écrit :

> Le 14 mars 2013 09:54, Vladimir Vyskocil  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 !)

[Philippe Verdy]

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  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 !)

[Philippe Verdy]

Le 14 mars 2013 09:54, Vladimir Vyskocil  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 !)

[CedricDV]

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  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 !)

[Vladimir Vyskocil]

Le drapeau c'est plutôt plutôt pour les ambassades, non ?
 
On 14 mars 2013, at 09:46, Francescu GAROBY  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 !)

[Frédéric Rodrigo]

Le 14 mars 2013 09:46, Francescu GAROBY  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 !)

[Francescu GAROBY]

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  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  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 !)

[Philippe Verdy]

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  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 !)

[Francescu GAROBY]

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  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 
>
>> 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 
>
> ___
> 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 !)

[Ista Pouss]

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 

> 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 
___
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 !)

[Christian Quest]

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 !)

[Sylvain Maillard]

Le 13 mars 2013 11:11, Christian Quest  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 !)

[Christian Quest]

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  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  a écrit
> :
>
>> Dans le genre plat de spaghetti, sur Lyon on a ça:
>> http://tile.openstreetmap.fr/?zoom=17&lat=45.77177&lon=4.78927&layers=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=18&lat=45.75133&lon=4.82329&layers=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=17&lat=45.78947&lon=4.86672&layers=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  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  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 !)

[Francescu GAROBY]

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  a
écrit :

> Dans le genre plat de spaghetti, sur Lyon on a ça:
> http://tile.openstreetmap.fr/?zoom=17&lat=45.77177&lon=4.78927&layers=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=18&lat=45.75133&lon=4.82329&layers=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=17&lat=45.78947&lon=4.86672&layers=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  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  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 !)

[Christian Quest]

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  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 !)

[Sylvain Maillard]

Dans le genre plat de spaghetti, sur Lyon on a ça:
http://tile.openstreetmap.fr/?zoom=17&lat=45.77177&lon=4.78927&layers=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=18&lat=45.75133&lon=4.82329&layers=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=17&lat=45.78947&lon=4.86672&layers=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  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  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 !)

[Francescu GAROBY]

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  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 !)

[Bruno Cortial]

Le 12 mars 2013 21:13, Vincent de Chateau-Thierry  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 !)

[Christian Quest]

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 !)

[Christian Quest]

Le 12 mars 2013 21:13, Vincent de Chateau-Thierry  a écrit :
> Bonjour,
>
> Le 11/03/2013 13:10, Christian Quest a écrit :
>
>> Le style est en place:
>>
>> http://tile.openstreetmap.fr/?zoom=19&lat=44.13525&lon=4.8059&layers=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 !)

[Vincent de Chateau-Thierry]

Bonjour,

Le 11/03/2013 13:10, Christian Quest a écrit :

Le style est en place:
http://tile.openstreetmap.fr/?zoom=19&lat=44.13525&lon=4.8059&layers=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 !)

[Christian Quest]

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=19&lat=48.8303&lon=2.49302&layers=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 !)

[Philippe Verdy]

> Le 12 mars 2013 12:30, Christian Quest  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 !)

[Vladimir Vyskocil]

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  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 !)

[Vladimir Vyskocil]

On 12 mars 2013, at 13:15, "Jo."  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  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 !)

[Jo.]

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  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 !)

[Christian Quest]

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 !)

[Vladimir Vyskocil]

On 12 mars 2013, at 10:38, Christian Quest  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 !)

[Philippe Verdy]

Le 12 mars 2013 10:09, Vincent Pottier  a écrit :
> Étrange là aussi :
> http://tile.openstreetmap.fr/?zoom=19&lat=46.36865&lon=5.95777&layers=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 !)

[Philippe Verdy]

Le 12 mars 2013 08:50, Vladimir Vyskocil  a écrit :
>
> On 11 mars 2013, at 21:45, Philippe Verdy  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 !)

[Christian Quest]

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  a écrit :
>
> On 12 mars 2013, at 09:14, Christian Quest  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 !)

[Christian Quest]

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  a écrit :
> J'ai la même à Caen :
> http://tile.openstreetmap.fr/?zoom=19&lat=49.18171&lon=-0.37274&layers=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  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=19&lat=48.72586&lon=4.58526&layers=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 !)

[Vladimir Vyskocil]

On 12 mars 2013, at 09:14, Christian Quest  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 !)

[RainerU]

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 !)

[RainerU]

> 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 !)

[Vincent Pottier]

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=19&lat=49.18318&lon=-0.38658&layers=B0 
et là : 
http://tile.openstreetmap.fr/?zoom=19&lat=49.18546&lon=-0.38354&layers=B0


Francescu


Étrange là aussi :
http://tile.openstreetmap.fr/?zoom=19&lat=46.36865&lon=5.95777&layers=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 !)

[Francescu GAROBY]

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=19&lat=49.18318&lon=-0.38658&layers=B0et
là :
http://tile.openstreetmap.fr/?zoom=19&lat=49.18546&lon=-0.38354&layers=B0

Francescu


Le 12 mars 2013 09:14, Christian Quest  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  a
> écrit :
> >
> > On 11 mars 2013, at 21:45, Philippe Verdy  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 !)

[Francescu GAROBY]

J'ai la même à Caen :
http://tile.openstreetmap.fr/?zoom=19&lat=49.18171&lon=-0.37274&layers=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  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=19&lat=48.72586&lon=4.58526&layers=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 !)

[Simon Miniou]

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=19&lat=48.72586&lon=4.58526&layers=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 !)

[Christian Quest]

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  a écrit :
>
> On 11 mars 2013, at 21:45, Philippe Verdy  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 !)

[Vladimir Vyskocil]

On 11 mars 2013, at 21:45, Philippe Verdy  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 !)

[Philippe Verdy]

Le 11 mars 2013 18:14, Vladimir Vyskocil  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 !)

[Christian Quest]

Le 11 mars 2013 18:14, Vladimir Vyskocil  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 !)

[Vladimir Vyskocil]

Le 11 mars 2013 à 17:12, Philippe Verdy  a écrit :

> Le 11 mars 2013 16:23, Vladimir Vyskocil  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 !)

[Philippe Verdy]

Le 11 mars 2013 16:23, Vladimir Vyskocil  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 !)

[Tetsuo Shima]

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  a écrit :
> Le 11 mars 2013 16:23, Vladimir Vyskocil  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 !)

[Christian Quest]

Le 11 mars 2013 16:23, Vladimir Vyskocil  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 !)

[Vladimir Vyskocil]

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 !)

[Philippe Verdy]

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  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 !)

[Christian Quest]

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 !)

[Christian Quest]

Le 11 mars 2013 14:48, Philippe Verdy  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 !)

[Philippe Verdy]

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 :
> 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 !)

[Philippe Verdy]

Le 11 mars 2013 13:03, Bruno Cortial  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 !)

[Christian Quest]

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 !)

[HELFER Denis]

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 !)

[Jo.]

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=19&lat=43.18267&lon=3.01662&layers=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  a écrit :

> 2013/3/11 Christian Quest :
> > Le style est en place:
> >
> http://tile.openstreetmap.fr/?zoom=19&lat=44.13525&lon=4.8059&layers=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_diff<30] {
> > 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 !)

[Cyrille Giquello]

2013/3/11 Christian Quest :
> Le style est en place:
> http://tile.openstreetmap.fr/?zoom=19&lat=44.13525&lon=4.8059&layers=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_diff<30] {
> 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 !)

[Christian Quest]

Le style est en place:
http://tile.openstreetmap.fr/?zoom=19&lat=44.13525&lon=4.8059&layers=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_diff<30] {
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 !)

[Philippe Verdy]

>>> 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 !)

[Bruno Cortial]

Le 11 mars 2013 12:55, Cyrille Giquello  a écrit :

> Le 11 mars 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
> >
> > 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 !)

[Cyrille Giquello]

Le 11 mars 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
>
> 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 !)

[Philippe Verdy]

Le 11 mars 2013 12:44, Philippe Verdy  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 !)

[Philippe Verdy]

Le 11 mars 2013 12:15, Christian Quest  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 !)

[JB]

 

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 !)

[Christian Quest]

Le 11 mars 2013 11:46, Vincent de Chateau-Thierry  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 !)

[Vincent de Chateau-Thierry]

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 !)

[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 ?

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 !)

[Philippe Verdy]

Le 22 février 2013 23:54, Vincent Pottier  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 !)

[djo_man]

  
  

Le 22/02/2013 16:02, ades_...@orange.fr
  a écrit :


  , 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. 



+1

bonjour, 

carrément en ce qui concerne le zoom 18 et 17 et pas seulement pour
repérer la 4ème maison. 

Il s'agit là bien de lire une information morphologique importante
qui en dit long culturellement. 

Du bati accolé sur des parcelles en lanières n'a rien à voir avec
une grosse longère 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 !)

[Vincent Pottier]

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 ?

http://wiki.openstreetmap.org/wiki/FR:Key:ele
--
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 !)

[Christian Quest]

Ce rendu "fr" n'est pas destiner à mapper, mais à présenter les données
avec un peu plus de traitement.

Exemple: les noms de rue abrégés pourraient te faire croire que le nom a
été rentré "Av. du Gal. de Gaulle", alors que dans la base il y a bien
"Avenue du Général de Gaulle".

Le rendu osm par défaut ou le rendu 2u seront plus adaptés à repérer cette
4ème maison.


Le 22 février 2013 16:02, 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 ? :-)



-- 
Christian Quest - OpenStreetMap France
Week-end "SOTM-FR" à Lyon, les 23-24 février prochains:
http://openstreetmap.fr/sotmfr2013
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr