Re: [OSM-talk-fr] Amélioration rendu "FR" sur les zooms faibles...

[djo_man]

  
  
bonjour, 

Que de difficultés pour "rendre" une carte à partir de données non
unifiées...

- Au zoom 9 ne faudrait-il pas rendre plus visibles les limites des
départements dans un violet leger?
(elles sont présentes mais quasi invisible)

- pour nommer les départements, une technique de violet gras
semi-transparent en très grosse typo qui pourrait être placé en fond
et recouvrable par la toponymie des villes serait peut être lisible
? serait-ce valable aussi pour les autres pays ?

- zoom 8 :un brin de présence supplémentaire pour les villes
d'envergures régionales serait-peut être mieux, en restant dans une
taille en dessous de celle des régions (voire augmenter celle des
régions?)

- à quoi la confiture ? ;)

djo_man

Le 17/08/2013 20:06, Christian Quest a
  écrit :


  J'ai modifié la requête pour les noms de capitales, en effet, le
schéma de tag est peu clair et il y a plein de variations:
- is_capital=country
- capital=yes + admin_level=2
- capital=2

La requête gère maintenant les 3 possibilités, et j'en ai profite pour
compléter les quelques capitales pour lesquelles il manquait des
infos.

Les zoom jusqu'à 7 ont été recalculés, c'est nettement mieux.
J'ai aussi mis les libellés un tout petit peu plus gros.


Autre changement majeur: un patch à mapnik pour gérer différemment les
limites entre metatile.
L'effet est qu'il y a beaucoup moins de textes et cartouches coupés.
Il m'en reste encore sur une requête très spéciale pour les noms de rues.

Dès que celle-ci sera corrigée et les tuiles recalculées, je lancerai
un concours où il y aura un pot de confiture (maison) à gagner si vous
trouvez un texte coupé ;)

___
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

[OSM-talk-fr] Nouveau Rendu des Tuiles France - partie 2

[HParv]

  
  
ici : http://c.tile.openstreetmap.fr/osmfr/11/1032/695.png



A présent une question : j'ai noté que http://tile.openstreetmap.fr/
était hébergé par Free (trop cool Free) sur des machines présentées
en lien.

Y-a-t-il des restrictions à prévoir en matière d'aspiration des
tuiles ? Il s'agit de pouvoir assurer une autarcie de fonctionnement
pour le système cartographique de plusieurs SAMU (aspiration
centralisée et redistribuée par le système d'information
multirégional). 

OSM , l'initiative qui réconcilie avec le genre humain !


Bien cordialement,
-- 
  Hugues P.
  GCS RRAMUHN
  

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

[OSM-talk-fr] [Rendu FR] Rivière qui disparaît au zoom 11

[Waxy]

Salut,

Ça se passe ici :

- 
http://tile.openstreetmap.fr/?zoom=10&lat=3.71303&lon=-53.26124&layers=B00FFF


Le morceau de la crique limonade apparaît sous l’aéroport de Saül.

- 
http://tile.openstreetmap.fr/?zoom=11&lat=3.59705&lon=-53.21445&layers=B00FFF


Plus de rivière :-(
Un dirty donne :
"Tile is clean. Last rendered at Wed Jul 17 01:50:04 2013. Last accessed 
at Sun Aug 18 15:06:59 2013. Stored in 
file:///var/lib/mod_tile/osmfr/11/0/0/35/222/8.meta


(Dates might not be accurate. Rendering time might be reset to an old 
date for tile expiry. Access times might not be updated on all file 
systems)"


- 
http://tile.openstreetmap.fr/?zoom=12&lat=3.57753&lon=-53.19412&layers=B00FFF


Rivière de retour :-)

Pourquoi un rendu qui remonte au 17 juillet pour le zoom 11 ?

@+

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

Re: [OSM-talk-fr] Amélioration rendu "FR" sur les zooms faibles...

[Christian Quest]

Le 18 août 2013 14:34, djo_man  a écrit :
> bonjour,
>
> Que de difficultés pour "rendre" une carte à partir de données non
> unifiées...
>
> - Au zoom 9 ne faudrait-il pas rendre plus visibles les limites des
> départements dans un violet leger?
> (elles sont présentes mais quasi invisible)
>

Oui, ça mérite d'être un peu plus visible.


> - pour nommer les départements, une technique de violet gras
> semi-transparent en très grosse typo qui pourrait être placé en fond et
> recouvrable par la toponymie des villes serait peut être lisible ? serait-ce
> valable aussi pour les autres pays ?
>

Pas évident que ça puisse convenir avec les algos de base.
En effet, si on met un texte en très gros et en placement libre (c'est
à dire sur lequel on peut placer d'autres choses, textes et icônes),
ça risque de se superposer dans les pays où les "départements" sont
très petits... il faudrait donc en plus avoir un garde fou sur la
superficie du département.

Pas simple, mais pas impossible.


> - zoom 8 :un brin de présence supplémentaire pour les villes d'envergures
> régionales serait-peut être mieux, en restant dans une taille en dessous de
> celle des régions (voire augmenter celle des régions?)
>

Là aussi, c'est pas simple sauf si on veut optimiser le résultat sur
la France quitte à avoir quelque chose de moins lisible ailleurs.
Regarde les pays voisins... notre tissus de 36000 communes fait qu'on
a beaucoup de "village" et peu de "town".


> - à quoi la confiture ? ;)
>

Au choix: fraises, groseilles, framboise, rhubarbe-banane, abricots,
toutes faites maison et siglées "OpenStreetMap" ;)

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Amélioration rendu "FR" sur les zooms faibles...

[Christian Quest]

Le 17 août 2013 20:06, Christian Quest  a écrit :
> Autre changement majeur: un patch à mapnik pour gérer différemment les
> limites entre metatile.
> L'effet est qu'il y a beaucoup moins de textes et cartouches coupés.
> Il m'en reste encore sur une requête très spéciale pour les noms de rues.
>
> Dès que celle-ci sera corrigée et les tuiles recalculées, je lancerai
> un concours où il y aura un pot de confiture (maison) à gagner si vous
> trouvez un texte coupé ;)

Ca progresse bien sur les frontières de metatiles... quasiment plus de
défauts à par un que j'ai identifié mais pas encore corrigé ;)

Le concours n'est pas ouvert, mais vous pouvez vous entrainer sur
http://tile.openstreetmap.fr/?layers=B00FFF (layer
"osmfr-lowzoom-test", c'est lui qui me sert de test).
Il faut être un peu patient car les tuiles ne pas précalculées (sauf
zoom 1 à 11 qui sont communs avec "osmfr"), mais cela permet de voir
plus facilement où se trouvent les limites des metatile lorsqu'on se
déplace et donc ça aide au repérage des défauts.

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

[OSM-talk-fr] Entreprises locales de distribution électrique en France

[François Lacombe]

Bonjour,

La page du wiki Power networks/France donnant déjà une idée de la
volumétrie des infrastructures du réseau public de distribution électrique
d'ERDF, j'ai trouvé intéressant de la mettre à jour avec celui des
entreprises locales de distribution.

http://wiki.openstreetmap.org/w/index.php?title=WikiProject_Power_networks/France&action=submit#Volum.C3.A9trie_des_installations_de_transport

En effet, ERDF n'est pas le seul concessionnaire de ce réseau et certaines
communes sont desservies par des régies ou autres.

Je n'ai mis que celles dont je pratique "régulièrement" le réseau,
n'hésitez-pas à ajouter la votre, avec la valeur du tag operator=* associée
en ajoutant une ligne dans le tableau (classé par département).


Merci par avance & bon dimanche.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouveau Rendu des tuiles France - partie 1

[Christian Quest]

Le 18 août 2013 15:27, HParv  a écrit :

>  Bonjour,
>
> J'ai regardé avec attention les modifications que @cq94 a réalisé; elles
> sont significatives !
>
> C'est vrai que le rendu primitif est fort plat. Mais j'ai été un peu
> surpris par l'approche "forêt" ; je m'attendais à une approche plus
> urbanistique.
>
> Au niveau 4, il y a un artefact de frontière sur la pointe Bretagne (vers
> Plogoff) qui fait apparaitre à tort un point (qui devient un trait de 5  à
> 9); étant donné qu'il s'agit d'un rendu France, ne peut-on envisager de
> figurer au moins Paris sinon la position et le nom des plus grandes
> métropoles ?
>
>
Oui, il y a encore quelques petits trucs à corriger sur les limites
administratives...



>  Au niveau 5, le nom de la Région Nord-Pas de Calais n'apparait pas; c'est
> dommage car c'est tout de même la 3ème région la plus peuplée hors Ile de
> France et la plus dense (?) ! Ne peut-on pas écrire sur deux lignes le nom
> "Nord-Pas-de-Calais" (comme on pourrait le faire pour les "deux Normandie"
> ? Au demeurant Paris s'affiche mais nous prive de Ile-de-France ?!
>
>
J'ai bien Nord-Pas-de-Calais... un problème de cache du navigateur ?

Et oui, il n'y a pas la place pour Paris et Ile-de-France... ces premiers
niveaux de zooms sont délicat car il y a peu de place !



> Au niveau 6, ça devrait être étudié par nos politiques pour refonder le
> découpage du territoire (je sors). On ne voit pas Nancy, seulement sa
> position  car le label est sans doute en conflit avec le nom de la région.
> Pourquoi montrer Rodez mais pas Arras ?
>
>
Le placement des noms de villes est fait en fonction de la place
disponible, il y en avait pour Rodez, mais pas assez pour Arras (en tenant
compte d'une marge importante autour pour éviter une trop forte densité de
noms).



> Ce qui m'intrigue c'est aussi le label "claix" qui apparait en
> Poitou-Charentes ou Vittel en Lorraine. (c'est un sponsor osm ?) ou encore
> Boussens (1000 hab !) en MyPi ?
>
>
C'est pareil... place disponible, mais je te rassure, les noms sont placés
par population décroissante, mais si y'a pas la place, y'a pas la place !



> Au niveau 7, ne pas voir Cherbourg-Octeville dans le 50 mais "Tourlaville"
> surprend.
>

Nom trop long qui vient en conflit avec Alderney juste à côté...



> Dans le 61, à choisir pourquoi Perrou et non Domfront ?
>
>

Sûrement une limite aussi du placement automatique.



>  Au niveau 8, j'ai découvert des communes dans mon département de
> naissance, le 76 ! C'est assez étrange de voir apparaitre "Heuqueville" ou
> "Néville" ou "Incheville" ou "Ardouval" là où on s'attend à voir Etretat ou
> St-Valéry-en-Caux ou "Eu" ou "Les-Grandes-Ventes" (ou mieux Neufchâtel en
> Bray)  !
>
>
Pareil

Pour faire mieux, il faudrait soit du prétraitement, soit une notion
d'importance directement dans les données.


Au niveau 10, la mention des aérodromes avec leur nom me parait poser
> problème. L'étiquette pour un nom souvent à rallonge (et un site tout de
> même très spécialisé et anecdotique si on veut parler que des aérodromes)
> prive du nom de la commune. Le picto éventuellement (encore que), le nom
> non !
>
>
Exact, je me suis fait la même remarque.
Le nom des aéroports ne viendra maintenant qu'en zoom 11, et celui des
aérodromes en zoom 12... au prochain recalcul.



> Au niveau 11, si pars de Rouen et que je prends la D6014 vers l'Est (vers
> Pontoise 95), je n'ai que des étiquettes D6014 et aucun nom de ville pour
> me repérer ! Le positionnement des étiquettes des axes principaux parait
> donc inapproprié ?! Le cartouche lui même parait massif.
>
>

Oui, un problème d'ordre de placement des noms de "village".
Dans les zooms précédents, ils viennent pour remplir les espaces vides,
donc sont moins prioritaires que le reste.
A partir des zoom 10 et 11, les cartouches avec les références de routes
font leur apparition, et là il faut que l'ordre de tracé change... le zoom
11 est une charnière pas encore bien huilée.



> J'ai aussi noté un soucis sur
>
> http://b.tile.openstreetmap.fr/osmfr/11/1031/694.png/
> http://b.tile.openstreetmap.fr/osmfr/11/1032/694.png/
>
> Le premier cartouche D925 en partant du Tréport n''est pas figuré pour sa
> partie droite dans la tuile de droite !
>
>

Oui, ce zoom n'a pas encore été recalculé avec les corrections pour éviter
ces découpes.


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouveau Rendu des Tuiles France - partie 2

[Christian Quest]

Aspirer les tuiles une à une est très peu efficace. Beaucoup de ressources
gâchées par des millions de requêtes HTTP pour récupérer à chaque fois
quelques dizaines de Ko.

Il faudrait voir si on peut mettre à dispo un accès aux tuiles précalculées
dans des formats comme le MBtile (une base SQlite qui contient les tuiles),
voire une synchro des metatiles par sync.

Le top de l'autonomie c'est bien sûr de mettre en place en local votre
propre serveur de tuiles... et sur une zone limitée (comme là où opère un
SAMU), ça ne nécessite pas d'énormes ressources.


Le 18 août 2013 15:28, HParv  a écrit :

>  ici : http://c.tile.openstreetmap.fr/osmfr/11/1032/695.png
> [image: http://c.tile.openstreetmap.fr/osmfr/11/1032/695.png]
>
>
> A présent une question : j'ai noté que http://tile.openstreetmap.fr/était 
> hébergé par Free (trop cool Free) sur des machines présentées en lien.
>
> Y-a-t-il des restrictions à prévoir en matière d'aspiration des tuiles ?
> Il s'agit de pouvoir assurer une autarcie de fonctionnement pour le système
> cartographique de plusieurs SAMU (aspiration centralisée et redistribuée
> par le système d'information multirégional).
>
> OSM , l'initiative qui réconcilie avec le genre humain !
>
>
> *Bien cordialement,*
> --
> Hugues P. GCS RRAMUHN
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Rendu FR] Rivière qui disparaît au zoom 11

[Christian Quest]

Le /dirty est désactivé sur les zooms 1 à 11.

Les tuiles ne correspondent donc peut être plus au données actuelles...

Le zoom 11 va être recalculé d'ici demain avec les dernières
améliorations du style.


2013/8/18 Waxy :
> Salut,
>
> Ça se passe ici :
>
> -
> http://tile.openstreetmap.fr/?zoom=10&lat=3.71303&lon=-53.26124&layers=B00FFF
>
> Le morceau de la crique limonade apparaît sous l’aéroport de Saül.
>
> -
> http://tile.openstreetmap.fr/?zoom=11&lat=3.59705&lon=-53.21445&layers=B00FFF
>
> Plus de rivière :-(
> Un dirty donne :
> "Tile is clean. Last rendered at Wed Jul 17 01:50:04 2013. Last accessed at
> Sun Aug 18 15:06:59 2013. Stored in
> file:///var/lib/mod_tile/osmfr/11/0/0/35/222/8.meta
>
> (Dates might not be accurate. Rendering time might be reset to an old date
> for tile expiry. Access times might not be updated on all file systems)"
>
> -
> http://tile.openstreetmap.fr/?zoom=12&lat=3.57753&lon=-53.19412&layers=B00FFF
>
> Rivière de retour :-)
>
> Pourquoi un rendu qui remonte au 17 juillet pour le zoom 11 ?
>
> @+
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

[OSM-talk-fr] Fwd: Doctorant Open Data

[Christian Quest]

Pour info... répondre directement à max...@michali.fr

-- Message transféré --
De :  
Date : 15 août 2013 16:11
Objet : [contact] [Informations sur l'association] Open Data
À : cont...@openstreetmap.fr


Maxime Michali (max...@michali.fr) a envoyé un message en utilisant le
formulaire de contact suivant : http://openstreetmap.fr/contact.

Bonjour,

Je suis doctorant en droit sur le thème de l'ouverture des données
publiques / l'open data. A ce titre, je m'intéresse aux différents acteurs
afin d'avoir le point de vue le plus complet possible sur cette question.

Je serais très heureux de connaître votre histoire par rapport à l'open
data. Je ne recherche pas de réponse à une liste pré-établie de
questions, chaque intervenant ayant des particularités à prendre en compte.
Toute information, anecdote ou réflexion sur le sujet peut être
enrichissante pour mon travail de recherche.

Cela peut concerner l'open data en général (qu'est-ce qui peut inciter un
entrepreneur à investir dans les données ouvertes, qu'est-ce qui peut être
un frein, qu'est-ce qui manque aujourd'hui à l'open data pour se
développer, s'il est préférable d'avoir des données brutes ou
pré-triées, un seul portail de données ou plusieurs…) ou faire le point
de manière plus personnelle sur votre expérience (l'histoire de votre
projet, qu'est-ce qui a été facile ou difficile, quels acteurs vous ont
entourés, avez-vous rencontré des difficultés juridiques et/ou techniques,
comment les avez-vous surmontées, est-ce que vous utilisez uniquement des
données brutes ou les mettez-vous en relation avec d'autres données, est-ce
que vous vous intéressez aux données personnelles, à celles des
entreprises, utilisez-vous le crowdsourcing et avez-vous eu des problèmes
avec, quels sont vos préoccupations ou vos bonnes surprises…).

Ce ne sont là que quelques pistes que vous êtes libres d'explorer ou non.
Tout retour, aussi insignifiant qu'il puisse vous sembler, sera enrichissant
et pertinent.  Par exemple, beaucoup de collectivités m'ont répondu
qu'elles n'avaient pas initié de procédure d'open data : mais chaque
échange  a fait émerger de nouvelles raisons de ne pas se lancer dans
l'open data et donc de comprendre quels étaient les obstacles.

Si vous souhaitez que votre participation reste anonyme ou que certaines
informations ne soient pas utilisées, vous pouvez tout à fait me le
signaler afin de respecter votre volonté. Je m'intéresse plus
spécifiquement aux questions juridiques, mais toute remarque sur l'open data
sera bonne à prendre (que ce soit sur les métadonnées, les formats, le
manque de cohérence à l'échelle nationale, etc.).

Je reste à votre disposition pour toute question sur ce projet.

Je vous remercie d'avoir pris le temps de me lire, et vous prie d'agréer,
Madame, Monsieur, l'expression de mes respectueuses salutations.

En espérant avoir de vos nouvelles bientôt,
Cordialement,
Maxime Michali
Juriste en propriété intellectuelle et nouvelles technologies
Doctorant sur l'open data
06.51.22.43.35
max...@michali.fr
http://www.michali.fr
@MaximeMichali



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

Re: [OSM-talk-fr] Nouveau Rendu des tuiles France - partie 1

[J.-Lys]

Ça n'est pas en France, mais puisqu'on en parle... aux niveaux 7 et 8,
Alderney /(ça devrait d'ailleurs être/ Aurigny /en français...)/ est affiché
en plus gros que Guernesey et Jersey, or Aurigny est une subdivision du
baillage de Guernesey et devrait être affiché une taille en dessous de
Guernesey, non ? Au niveau 6 c'est pire : Aurigny et Sercq /(autre
dépendance de Guernesey)/ sont nommés en mauve et Guernesey n'apparaît pas.

J.-Lys



--
View this message in context: 
http://gis.19327.n5.nabble.com/Nouveau-Rendu-des-tuiles-France-partie-1-tp5773924p5773943.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Nouveau Rendu des Tuiles France - partie 2

[PhQ]

Il faudrait voir si on peut mettre à dispo un accès aux tuiles précalculées
dans des formats comme le MBtile (une base SQlite qui contient les tuiles),
voire une synchro des metatiles par sync.

Le top de l'autonomie c'est bien sûr de mettre en place en local votre
propre serveur de tuiles... et sur une zone limitée (comme là où opère un
SAMU), ça ne nécessite pas d'énormes ressources.


/Mode je réinvente la roue
Y a t'il une appli Window ou Linux précompilé qui permette de générer un
fond à partir des fichiers généré pour osmand, (obf) et  pas en simulant
android ?
Mode je réinvente la roue/



--
View this message in context: 
http://gis.19327.n5.nabble.com/Nouveau-Rendu-des-Tuiles-France-partie-2-tp5773925p5773946.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-talk-fr] Comment dessiner/taguer une île au milieu d'un lac avec plus de 2000 noeuds ?

[Severin MENARD]

Bonjour,

J'ai précisé le contour de l'île au centre du lac de
Baringo au
Kenya. L'ensemble fait plus de 2000 nœuds et j'ai eu du coup un message
d'erreur au moment d'uploader la donnée, la limite étant apparemment de
2000. L'île faisait déjà partie d'un multipolygone en tant que inner du
lac. Et le closedway de l'île était tagué place=island. Je l'ai scindé en
deux ways, me conformant à cette
pagede
méthodologie dans le wiki OSM, mais évidemment le Validator a râlé de
voir un tag place=island appliqué à un way non fermé. Cependant, compte
tenu de la position des nœuds où j'ai appliqué la coupure du closedway,
cela n'a pas de répercussion dommageable sur le rendu Mapnik.
Quelle devrait être la façon correcte de faire ?

Bien cordialement,

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

Re: [OSM-talk-fr] Comment dessiner/taguer une île au milieu d'un lac avec plus de 2000 noeuds ?

[David Crochet]

Bonjour

Le 18/08/2013 18:51, Severin MENARD a écrit :

Quelle devrait être la façon correcte de faire ?


Ce n'est pas parce que le "Validator" n'est pas d'accord que tu peut le 
passer outre.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Comment dessiner/taguer une île au milieu d'un lac avec plus de 2000 noeuds ?

[Christian Quest]

place=island devrait aller sur un autre multipolygone pour décrire
l'île, et rien sur les ways qui la compose.

En plus ça permet d'avoir une cohérence "un object physique", "un
tag"... là tu as 2 place=island, non ?

Au final on a donc:
- une relation type=multipolygon pour le lac, avec ces 2 ways en inner
- une relation type=multipolygon pour l'île (qui du coup peut avoir un
nom, etc), avec ces 2 ways en outer + type=multipolygone +
place=island, et aucun tag sur les way...


Le 18 août 2013 18:51, Severin MENARD  a écrit :
> Bonjour,
>
> J'ai précisé le contour de l'île au centre du lac de Baringo au Kenya.
> L'ensemble fait plus de 2000 nœuds et j'ai eu du coup un message d'erreur au
> moment d'uploader la donnée, la limite étant apparemment de 2000. L'île
> faisait déjà partie d'un multipolygone en tant que inner du lac. Et le
> closedway de l'île était tagué place=island. Je l'ai scindé en deux ways, me
> conformant à cette page de méthodologie dans le wiki OSM, mais évidemment le
> Validator a râlé de voir un tag place=island appliqué à un way non fermé.
> Cependant, compte tenu de la position des nœuds où j'ai appliqué la coupure
> du closedway, cela n'a pas de répercussion dommageable sur le rendu Mapnik.
> Quelle devrait être la façon correcte de faire ?
>
> Bien cordialement,
>
> Séverin
> HOT
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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

[OSM-talk-fr] Comment dessiner/taguer une île au milieu d'un lac avec plus de 2000 noeuds ?

[Severin MENARD]

Merci de l'info, c'est effectivement le plus logique ! J'ai corrigé ainsi.



> Date: Sun, 18 Aug 2013 19:22:38 +0200
> From: Christian Quest 
> To: Discussions sur OSM en français  
> Subject: Re: [OSM-talk-fr] Comment dessiner/taguer une île au milieu
> d'un lac avec plus de 2000 noeuds ?
> Message-ID:
> <
> caaxy6dp1nc4vzodkzvps_g8wjk4zce2s8+xqo+1h-mgggxb...@mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> place=island devrait aller sur un autre multipolygone pour décrire
> l'île, et rien sur les ways qui la compose.
>
> En plus ça permet d'avoir une cohérence "un object physique", "un
> tag"... là tu as 2 place=island, non ?
>
> Au final on a donc:
> - une relation type=multipolygon pour le lac, avec ces 2 ways en inner
> - une relation type=multipolygon pour l'île (qui du coup peut avoir un
> nom, etc), avec ces 2 ways en outer + type=multipolygone +
> place=island, et aucun tag sur les way...
>
>
> Le 18 août 2013 18:51, Severin MENARD  a écrit :
> > Bonjour,
> >
> > J'ai précisé le contour de l'île au centre du lac de Baringo au Kenya.
> > L'ensemble fait plus de 2000 n?uds et j'ai eu du coup un message
> d'erreur au
> > moment d'uploader la donnée, la limite étant apparemment de 2000. L'île
> > faisait déjà partie d'un multipolygone en tant que inner du lac. Et le
> > closedway de l'île était tagué place=island. Je l'ai scindé en deux
> ways, me
> > conformant à cette page de méthodologie dans le wiki OSM, mais
> évidemment le
> > Validator a râlé de voir un tag place=island appliqué à un way non fermé.
> > Cependant, compte tenu de la position des n?uds où j'ai appliqué la
> coupure
> > du closedway, cela n'a pas de répercussion dommageable sur le rendu
> Mapnik.
> > Quelle devrait être la façon correcte de faire ?
> >
> > Bien cordialement,
> >
> > Séverin
> > HOT
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
>
>
> --
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
> Fin de Lot Talk-fr, Vol 85, Parution 70
> ***
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouveau Rendu des Tuiles France - partie 2

[Philippe Verdy]

Il y a une autre solution, déjà proposée par Mapquest, qui consiste à
retourner à la demande en en une seule requête un assemblage de tuiles
précalculées.

Cela génère une image unique directement, sans avoir besoin d'un format
"exotique" comme MBTile (qui est un format d'image sauf qu'il est plus
gourmand encore car l'image est décomposée en série de tuiles et contient
un index; MBTile est économique surtout pour les carte maritimes ou
déseriques où de nombreuses tuiles élémentaire seraient totalement
identiques entre elles (uniformément unicolores), mais le format PNG (et
même le format JPEG) inclue déjà une compression interne qui compresse déjà
très bien ces zones formées de bandes de tuiles identiques.

MBTile n'est intéressant en fait que pour le stockage de plusieurs niveaux
de zoom avec de grandes similitudes entre les niveaux, si les niveaux sont
compressés de façon différentielle (et à condition qu'il n'y ait pas trop
de libellés car les tailles de polices des libellés ne suivent pas la règle
de proportionnalité, et pas trop de routes non plus car elles aussi ont des
largeurs de traits non proportionnelles). Il marcherait bien pour le
stockage d'orthophotographie aérienne ou satellitaire, mais là encore JPEG
et PNG incluent un support pour une compression en mode "progressif".

Certes cela demande un peu de ressources sur le serveur qui doit réaliser
l'assemblage (mais l'assemblage en bandes verticales est trivial et très
peu coûteux, ce n'est pratiquement qu'une concaténation sans avoir à
traiter les images sources ligne par ligne; à condition que les images
sources utilisent les mêmes paramètres de compression (pas garanti avec
JPEG où les tables de codage Huffman son différentes) et de palettes si ce
n'est pas un stockage où les pixels codent directement la couleur (pas
garanti avec PNG si il utilise une compression des couleurs par indirection
via une palette spécifique à chaque image).

MBTile ne m'a jamais bien convaincu, face aux formats de compression
d'image d'aujourd'hui.


Le 18 août 2013 16:53, Christian Quest  a écrit :

> Aspirer les tuiles une à une est très peu efficace. Beaucoup de ressources
> gâchées par des millions de requêtes HTTP pour récupérer à chaque fois
> quelques dizaines de Ko.
>
> Il faudrait voir si on peut mettre à dispo un accès aux tuiles
> précalculées dans des formats comme le MBtile (une base SQlite qui contient
> les tuiles), voire une synchro des metatiles par sync.
>
> Le top de l'autonomie c'est bien sûr de mettre en place en local votre
> propre serveur de tuiles... et sur une zone limitée (comme là où opère un
> SAMU), ça ne nécessite pas d'énormes ressources.
>
>
> Le 18 août 2013 15:28, HParv  a écrit :
>
>>  ici : http://c.tile.openstreetmap.fr/osmfr/11/1032/695.png
>> [image: http://c.tile.openstreetmap.fr/osmfr/11/1032/695.png]
>>
>>
>> A présent une question : j'ai noté que http://tile.openstreetmap.fr/était 
>> hébergé par Free (trop cool Free) sur des machines présentées en lien.
>>
>> Y-a-t-il des restrictions à prévoir en matière d'aspiration des tuiles ?
>> Il s'agit de pouvoir assurer une autarcie de fonctionnement pour le système
>> cartographique de plusieurs SAMU (aspiration centralisée et redistribuée
>> par le système d'information multirégional).
>>
>> OSM , l'initiative qui réconcilie avec le genre humain !
>>
>>
>> *Bien cordialement,*
>> --
>> Hugues P. GCS RRAMUHN
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
> ___
> 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] Entreprises locales de distribution électrique en France

[Philippe Verdy]

Pour les Deux-Sèvres, il manque Seolis (http://www.seolis.net)



Le 18 août 2013 16:30, François Lacombe <
francois.laco...@telecom-bretagne.eu> a écrit :

> Bonjour,
>
> La page du wiki Power networks/France donnant déjà une idée de la
> volumétrie des infrastructures du réseau public de distribution électrique
> d'ERDF, j'ai trouvé intéressant de la mettre à jour avec celui des
> entreprises locales de distribution.
>
>
> http://wiki.openstreetmap.org/w/index.php?title=WikiProject_Power_networks/France&action=submit#Volum.C3.A9trie_des_installations_de_transport
>
> En effet, ERDF n'est pas le seul concessionnaire de ce réseau et certaines
> communes sont desservies par des régies ou autres.
>
> Je n'ai mis que celles dont je pratique "régulièrement" le réseau,
> n'hésitez-pas à ajouter la votre, avec la valeur du tag operator=* associée
> en ajoutant une ligne dans le tableau (classé par département).
>
>
> Merci par avance & bon dimanche.
>
>
> *François Lacombe*
>
> francois dot lacombe At telecom-bretagne dot eu
> http://www.infos-reseaux.com
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Entreprises locales de distribution électrique en France

[François Lacombe]

Merci :)

Ajouté avec operator=Seolis (7 objets correspondant aux bâtiments de leur
siege existent déjà à Niort).

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


Le 18 août 2013 20:35, Philippe Verdy  a écrit :

> Pour les Deux-Sèvres, il manque Seolis (http://www.seolis.net)
>
>
>
> Le 18 août 2013 16:30, François Lacombe <
> francois.laco...@telecom-bretagne.eu> a écrit :
>
>> Bonjour,
>>
>> La page du wiki Power networks/France donnant déjà une idée de la
>> volumétrie des infrastructures du réseau public de distribution électrique
>> d'ERDF, j'ai trouvé intéressant de la mettre à jour avec celui des
>> entreprises locales de distribution.
>>
>>
>> http://wiki.openstreetmap.org/w/index.php?title=WikiProject_Power_networks/France&action=submit#Volum.C3.A9trie_des_installations_de_transport
>>
>> En effet, ERDF n'est pas le seul concessionnaire de ce réseau et
>> certaines communes sont desservies par des régies ou autres.
>>
>> Je n'ai mis que celles dont je pratique "régulièrement" le réseau,
>> n'hésitez-pas à ajouter la votre, avec la valeur du tag operator=* associée
>> en ajoutant une ligne dans le tableau (classé par département).
>>
>>
>> Merci par avance & bon dimanche.
>>
>>
>> *François Lacombe*
>>
>> francois dot lacombe At telecom-bretagne dot eu
>> http://www.infos-reseaux.com
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Pour les tuiles / SAMU

[HParv]

Merci pour les avis. Je suis d'accord que l'aspiration http partie par 
partie est assez peu performante au moins en temps. Je prends note de 
vos suggestions et reviendrait vers vous aussi vite que mon emploi du 
temps me le permettra !


A suivre
--
Hugues P. GCS RRAMUHN
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Amélioration rendu "FR" sur les zooms faibles...

[Philippe Verdy]

Le 18 août 2013 16:13, Christian Quest  a écrit :

>
> Au choix: fraises, groseilles, framboise, rhubarbe-banane, abricots,
> toutes faites maison et siglées "OpenStreetMap" ;)
>

Question goût, que dire de "rhubarbe-banane" ? Avec de la rhubarbe fraiche
OK, mais pas avec les bananes importées, même bio. Association étrange de
gout et texture entre l'acidité et l'amertume de la rhubarbe (qu'on
apprécie aussi pour sa texture filandreuse), et la douceur sucrée mais sa
texture très pâteuse.

Pour moi une bonne confiture ne mélange pas les fruits pour que chacun soit
cuit de façon optimale sans perdre ses goûts spécifiques et sa texture.
Banane et rhubarbe ne peuvent pas cuire aussi longtemps l'un que l'autre
(on doit monter davantage en température pour la rhubarbe pour lui faire
perdre aussi plus d'eau, alors que si on fait ça à la banane, on la
brûle... Et la rhubarbe pas assez cuite est franchement pas terrible en
confiture. Les deux fruits ne demandent pas non plus la même quantité de
sucre.

Si on veut un mélange de fruit, on le fait après cuisson au moment de
servir, c'est bien meilleur. Si on ajoute des épices (poivre, cannelle...),
c'est seulement après cuisson dans les fruits encore chauds (mais pas trop
sinon on dégrade les arômes de l'épice qui donnent laors mauvais goût).

Moi je fais mes propres compotes de pomme, et j'y met du poivre (que je
trouve bien meilleur et moins lourd que la cannelle utilisée juste dans la
pâtisserie bon marché avec des pommes de mauvaise qualité) et des zestes de
citron (le jus de citron c'est dès le début de cuisson pour éviter
l'oxydation) ; variantes épicées possibles aussi avec l'anis étoilé (moulu
et entier) ou la cardamome.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nominatim et les articles

[Yves Pratter]

> On pourrait y ajouter :
> 
> le, la, les, l'
> de, du, des, d'
> sur, sous, s/, s/s
> ès

La liste des mots vides de solr se trouve ici :
https://github.com/documentcloud/documentcloud/tree/master/solr/collection1/conf/lang

Elle existe dans toutes une trentaine de langues.

Pour info, on retrouve ça dans les SIGB (les logiciels de gestion de 
bibliothèques) — entre-autres.

En ce qui concerne des noms de rues, comment gérer "Rue Gustave Eiffel 
Pontarlier" ?

Faut-il mettre une liste :
de noms propres avec la partie "vide", ici le prénom ?
de prénoms ?
de mots vides contenant les prénoms ?

Comment traiter le type de voirie si il est erroné ?

--
Yves


PS:
requête ne renvoyant rien :
Rue Eiffel Pontarlier
Rue Gustave Pontarlier
avenue Gustave Eiffel Pontarlier
requêtes fonctionnant :
Rue Gustave Eiffel Pontarlier
gustave pontarlier
gustave doubs
Gustave Eiffel Pontarlier
eiffel pontarlier
eiffel doubs

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

[OSM-talk-fr] Recherches limitées à la France sur tile.openstreetmap.fr

[Yves Pratter]

Bonsoir,

En faisant un test avec nominatim, voici un résultat un peu curieux ;-)
http://tile.openstreetmap.fr/?q=Eiffel

Eiffel, Jipijapa, Quito, Cantón Quito, Provincia de Pichincha, Équateur
Eiffel, Iglesia San Francisco, Arica, Provincia de Arica, Région d'Arica et 
Parinacota, Chili
Eiffel, El Avellano, Los Angeles, Provincia de Bío-Bío, Biobío, Chili
Eiffel, Calle de Seseña, Latina, Madrid, Área metropolitana de Madrid y 
Corredor del Henares, Madrid, 28047, Espagne, European Union
Eiffel, 2, Lamač, okres Bratislava IV, Bratislava, Bratislavský kraj, 84551, 
Slovaquie, European Union
Eiffel, Avenida Ayrton Senna, Barra da Tijuca, Rio de Janeiro, Microrregião Rio 
de Janeiro, Região Metropolitana do Rio de Janeiro, Rio de Janeiro, Região 
Sudeste, 22775-900, Brésil
EIFFEL, Route de la Baie des Dames, Ducos Industriel, Ducos Zone Industrielle, 
Nouméa, Province Sud, Nouvelle-Calédonie - ZEE, 98863, Nouvelle-Calédonie — 
eaux territoriales
Eiffel, Viale Alexandre Gustave Eiffel, Ponte Galeria, Municipio Roma XI, Rome, 
Latium, 00125, Italie, European Union
Eiffel, Chemin des Vassues, Vitry-le-François, Marne, Champagne-Ardenne, 51300, 
France, European Union
Eiffel, Resistenza Partigiana, Modica, RG, Sicile, Italie

Recherche limitée à la France. Masquer les résultats

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

Re: [OSM-talk-fr] Nominatim et les articles

[Francescu GAROBY]

Je pense aussi que Nominatim ne devrait pas être si "à cheval" sur le type
de routes : rue, avenue, boulevard, ... Il n'est pas rare de se tromper et,
dans le cas où on ne connait pas le type exact, de taper "rue" à défaut
d'autre chose.

Francescu


Le 18 août 2013 21:17, Yves Pratter  a écrit :

> On pourrait y ajouter :
>
> le, la, les, l'
> de, du, des, d'
> sur, sous, s/, s/s
> ès
>
>
> La liste des *mots vides* de solr se trouve ici :
>
> https://github.com/documentcloud/documentcloud/tree/master/solr/collection1/conf/lang
>
> Elle existe dans toutes une trentaine de langues.
>
> Pour info, on retrouve ça dans les 
> SIGB
>  (les
> logiciels de gestion de bibliothèques) — entre-autres.
>
> En ce qui concerne des noms de rues, comment gérer "Rue Gustave Eiffel
> Pontarlier" ?
>
> Faut-il mettre une liste :
>
>- de noms propres avec la partie "vide", ici le prénom ?
>- de prénoms ?
>- de mots vides contenant les prénoms ?
>
>
> Comment traiter le type de voirie si il est erroné ?
>
> --
> Yves
>
>
> PS:
>
>- requête ne renvoyant rien :
>   - Rue Eiffel Pontarlier
>   - Rue Gustave Pontarlier
>   - avenue Gustave Eiffel Pontarlier
>- requêtes fonctionnant :
>   - Rue Gustave Eiffel Pontarlier
>   - gustave pontarlier
>   - gustave doubs
>   - Gustave Eiffel Pontarlier
>   - eiffel pontarlier
>   - eiffel doubs
>
>
>
> ___
> 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] Nouveau Rendu des Tuiles France - partie 2

[Christian Quest]

Le 18 août 2013 20:18, Philippe Verdy  a écrit :

>
> MBTile ne m'a jamais bien convaincu, face aux formats de compression
> d'image d'aujourd'hui.
>
>
... pour la simple et bonne raison que MBtile n'est pas un format de
compression d'image, mais simplement un moyen de stocker des images (JPEG,
PNG, etc) dans un seul fichier (SQlite), de façon plus économe en espace
disque que sur les filesystem courants. La seule "compression"
additionnelle se fait sur les images absolument identiques (le bleu uni de
la mer par exemple).

Il suffit de lire ne serait-ce que l'intro sur
http://www.mapbox.com/developers/mbtiles/ pour comprendre de quoi il s'agit
exactement, car ça n'a aucun rapport avec ce que tu écris comme les
compressions en mode progressif ou les palettes de couleur.

C'est marrant, en te lisant ça me fait penser aux articles de journalistes
qui ne connaissent pas un sujet, mais qui écrivent de beaux articles.

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nominatim et les articles

[Christian Quest]

Pour cela il faudrait qu'on décrive mieux les noms en général en les
découpants:

Rue Gustave Eiffel

Rue = type de voie, féminin*
Gustave = signifiant optionnel
Eiffel = signifiant principal

* pour permettre les accords dans des outils de vocalisation comme le
guidage audio

Certaines choses peuvent être traitées automatiquement, il faudrait tagguer
que les cas particuliers non gérables par un algorithme sans info
complémentaire (exemple avec "Tour" qui peut être masculin ou féminin).



Le 18 août 2013 21:24, Francescu GAROBY  a écrit :

> Je pense aussi que Nominatim ne devrait pas être si "à cheval" sur le type
> de routes : rue, avenue, boulevard, ... Il n'est pas rare de se tromper et,
> dans le cas où on ne connait pas le type exact, de taper "rue" à défaut
> d'autre chose.
>
> Francescu
>
>
> Le 18 août 2013 21:17, Yves Pratter  a écrit :
>
>> On pourrait y ajouter :
>>
>> le, la, les, l'
>> de, du, des, d'
>> sur, sous, s/, s/s
>> ès
>>
>>
>> La liste des *mots vides* de solr se trouve ici :
>>
>> https://github.com/documentcloud/documentcloud/tree/master/solr/collection1/conf/lang
>>
>> Elle existe dans toutes une trentaine de langues.
>>
>> Pour info, on retrouve ça dans les 
>> SIGB
>>  (les
>> logiciels de gestion de bibliothèques) — entre-autres.
>>
>> En ce qui concerne des noms de rues, comment gérer "Rue Gustave Eiffel
>> Pontarlier" ?
>>
>> Faut-il mettre une liste :
>>
>>- de noms propres avec la partie "vide", ici le prénom ?
>>- de prénoms ?
>>- de mots vides contenant les prénoms ?
>>
>>
>> Comment traiter le type de voirie si il est erroné ?
>>
>> --
>> Yves
>>
>>
>> PS:
>>
>>- requête ne renvoyant rien :
>>   - Rue Eiffel Pontarlier
>>   - Rue Gustave Pontarlier
>>   - avenue Gustave Eiffel Pontarlier
>>- requêtes fonctionnant :
>>   - Rue Gustave Eiffel Pontarlier
>>   - gustave pontarlier
>>   - gustave doubs
>>   - Gustave Eiffel Pontarlier
>>   - eiffel pontarlier
>>   - eiffel doubs
>>
>>
>>
>> ___
>> 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
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rendu des libellés bidirectionnels (support pour l'écriture arabe ou hébreu)

[Philippe Verdy]

http://www.openstreetmap.org/#map=19/36.25233/1.97501

On constate ici dans TOUS les rendus Mapnik un bogue pour l'affichage des
textes bidirectionnels : l'affichage n'est correct QUE s'il n'y a pas de
saut de ligne au milieu du libellé

Ainsi un libellé bilingue comme:
  "Nom latin - NOM ARABE"
devient bien après réordonnancement linéaire des glyphes (sur une seule
ligne):
  "Nom latin - EBARA MON"

Mais ça se complique en cas de saut de ligne (pour des libellés trop longs,
ou contenant des espaces):
  "Nom latin"
  "- EBARA"
  "MON"
est complètement faux, alors que la solution correcte serait plutôt:
  "Nom latin"
  "- MON"
  "EBARA"

Autrement dit ce n'est pas parce que la partie écrite en arabe se lit de
droite à gauche qu'il faut couper la partie coupée à droite et la placer
SOUS la partie conservée à gauche.

Mapnik ne respecte donc pas l'ordre des mots car même en arabe les lignes
se lisent du haut vers le bas et nom du bas vers le haut.

Le rendu bidirectionnel Mapnik (nécessaire pour l'arabe, l'hébreu) est faux
partout aussi bien sur le site .org que sur les rendus français et même
d'autres (OpenCycleMap, etc.).

A qui renvoyer l'anomalie?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Nominatim et les codes postaux

[Yves Pratter]

Bonsoir,

Ne connaissant pas le village de Vers situé dans mon département natal, je 
questionne Nominatim et m'attends à avoir une réponse unique :
vers 74160 renvoi :
Vers, Saône-et-Loire, Bourgogne, 71240, France, European Union
Vers, Saint-Julien-en-Genevois, Haute-Savoie, Rhône-Alpes, 74160, France, 
European Union
Vers, Albi, Tarn, Midi-Pyrénées, France, European Union
Vers, Cahors, Lot, Midi-Pyrénées, 46090, France, European Union
Le Vers, Saint-Martin-de-Vers, Cahors, Lot, Midi-Pyrénées, 46360, France, 
European Union
Vers, France
Le Vers, France
Le Vers, France
Vers, France
Vers, France

vers savoie ou haute savoie renvoient bien un résultat unique :
Vers, Saint-Julien-en-Genevois, Haute-Savoie, Rhône-Alpes, 74160, France, 
European Union


Il semble donc que nominatim (du moins en France) ne tienne pas compte des 
codes postaux.

PS: j'ai essayé avec brighton BN1 et ça ne tient pas compte non plus du 
résultat.

PS bis : au passage, pourquoi 3 Vers, France et 2 Le Vers, France ??


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

[OSM-talk-fr] Nominatim : type d'objets OSM retrouvés

[Yves Pratter]

Rebonsoir,

La recherche Gustave Eiffel donne des résultats "un peu" différents suivant les 
serveurs.
Concrètement, les résultats sur le serveur français sont un peu déroutant. J'ai 
du allez voir le lieux avec un éditeur OSM pour comprendre que la première 
adresse était la tombe de Gustave ;-D

L'affichage (en fin de ligne) du type d'adresse pourrait-être utile ;-)

Au passage, où traduire Grave pour www.openstreetmap.org (et d'autres) 
l'affichent correctement en français ?

--
Yves

tile.openstreetmap.fr
Gustave Eiffel, Route d'Asnières, Clichy, Nanterre, Hauts-de-Seine, 
Île-de-France, 92300, France, European Union
Gustave Eiffel, Lunel, Montpellier, Hérault, Languedoc-Roussillon, 34400, 
France, European Union
Gustave Eiffel, Keltenring, Marmagen, Euskirchen, District de Cologne, 
Rhénanie-du-Nord-Westphalie, 53947, Allemagne, European Union
Gustave Eiffel, Boulevard Pierre et Marie Curie, Chasseneuil-du-Poitou, 
Poitiers, Vienne, Poitou-Charentes, 86963, France, European Union
Gustave Eiffel, Avenue de Monsieur Teste, La Martelle, Les Cévennes, 
Montpellier, Hérault, Languedoc-Roussillon, 34990, France, European Union
Gustave Eiffel, Boulevard des Chênes, Guyancourt, Versailles, Yvelines, 
Île-de-France, 78280, France, European Union

www.openstreetmap.org

Grave Gustave Eiffel, Route d'Asnières, Clichy, Nanterre, Hauts-de-Seine, 
Île-de-France, 92300, France, European Union
Voir les détails
Rue résidentielle Gustave Eiffel, Lunel, Montpellier, Hérault, 
Languedoc-Roussillon, 34400, France, European Union
Afficher les détails
Arrêt de bus Gustave Eiffel, Avenue de Monsieur Teste, La Martelle, Les 
Cévennes, Montpellier, Hérault, Languedoc-Roussillon, 34990, France, European 
Union
Voir les détails
Arrêt de bus Gustave Eiffel, Boulevard Pierre et Marie Curie, 
Chasseneuil-du-Poitou, Poitiers, Vienne, Poitou-Charentes, 86963, France, 
European Union
Voir les détails
Mémorial Gustave Eiffel, Keltenring, Marmagen, Euskirchen, District de Cologne, 
Rhénanie-du-Nord-Westphalie, 53947, Allemagne, European Union
Voir les détails
Arrêt de bus Gustave Eiffel, Boulevard des Chênes, Guyancourt, Versailles, 
Yvelines, Île-de-France, 78280, France, European Union

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

Re: [OSM-talk-fr] Nouveau Rendu des Tuiles France - partie 2

[Philippe Verdy]

Je maintiens entièrement ce que j'ai écrit. Et je connaissiasi déjà le
sujet, pas la peine de me renvoyer à cette page.

MBTiles est bien un format d'image même s'il contient en interne des
sous-images, son but est de stocker une image plus grande afin de pouvoir
la servir facilement par morceaux sans avoir à faire des calculs
compliqués. Mais c'est un format spécifique qui ne se justifie plus du tout.

Bref tu me fais penser à ces journalistes qui ne lisent pas les sujets
écrits par d'autres, juste pour en comprendre le principe de base  et
écrivent de belles critiques en prétendant que l'autre ne connait rien et
n'a rien lu de sa part. C'est juste insultant, et je te renvoie l'insulte.

Et oui cela a aussi bien à voir avec l'affichage progressif (note bien que
je n'en ai parlé QUE dans le contexte du sockage de niveaux de zooms
multiples). Dans les rendus 3D on utilise des formats progressifs pour les
textures, ou des formats utilisant des textures mutliples avec des
techniques dites de "mipmapping" avec ou sans stockage différentiel, avec
ou sans interpolation et on parle bien du même sujet là aussi même si les
techniques son différentes.

Je renvient donc à la solution proposée par Mapquest qui s'avère efficace
et peu couteuse sur le serveur surtout pour retourner des bandes verticales
de tuiles plus grosses qu'une seule tuile unitaire, car il est possible de
le faire sans aucune transformation compliquée et au fil de l'eau, et sans
avoir à faire de nombreuses requêtes HTTP. Mapquest le propose pour
composer des images de taille arbitraire (mais dans une limite de taille
raisonnable). Il permet donc de réduire considérablement le nombre de
requêtes : tout serveur devrait être capable de composer à la demande des
images de taille plus importante que 256x256, et on devrait pouvoir lui
demander aussi 1024x1024 et diviser le nombre de requêtes par 16.

D'ailleurs le serveur effectue déjà un traitement graphique (ave nécessité
de recompresser l'image produite) pour retourner des tuiles unitaires
qu'ils stocke sous forme de métatuiles plus grandes, et je ne vois même pas
pourquoi il ne peut pas retourner directement une "métatuile" entière
directement sans aucun calcul.

Le 18 août 2013 21:31, Christian Quest  a écrit :

> Le 18 août 2013 20:18, Philippe Verdy  a écrit :
>
>>
>> MBTile ne m'a jamais bien convaincu, face aux formats de compression
>> d'image d'aujourd'hui.
>>
>>
> ... pour la simple et bonne raison que MBtile n'est pas un format de
> compression d'image, mais simplement un moyen de stocker des images (JPEG,
> PNG, etc) dans un seul fichier (SQlite), de façon plus économe en espace
> disque que sur les filesystem courants. La seule "compression"
> additionnelle se fait sur les images absolument identiques (le bleu uni de
> la mer par exemple).
>
> Il suffit de lire ne serait-ce que l'intro sur
> http://www.mapbox.com/developers/mbtiles/ pour comprendre de quoi il
> s'agit exactement, car ça n'a aucun rapport avec ce que tu écris comme les
> compressions en mode progressif ou les palettes de couleur.
>
> C'est marrant, en te lisant ça me fait penser aux articles de journalistes
> qui ne connaissent pas un sujet, mais qui écrivent de beaux articles.
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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] Nominatim : type d'objets OSM retrouvés

[Christian Quest]

Le 18 août 2013 21:52, Yves Pratter  a écrit :

> Rebonsoir,
>
> La recherche *Gustave Eiffel *donne des résultats "un peu" différents
> suivant les serveurs.
> Concrètement, les résultats sur le serveur français sont un peu déroutant.
> J'ai du allez voir le lieux avec un éditeur OSM pour comprendre que la
> première adresse était la tombe de Gustave ;-D
>

C'est bien la réponse la plus pertinente !
Je l'avais remarqué en ajoutant celle de Jim Morrison au père Lachaise.


> L'affichage (en fin de ligne) du type d'adresse pourrait-être utile ;-)
>

Tu parle de la présentation de la recherche Nominatim sur
tile.openstreetmap.fr ?
C'est super basique, toute l'interface est brute de décoffrage
essentiellement destinée à consulter les tuiles des différents rendu (d'où
son nom "tile"), pas vraiment à fournir un service plus aboutit... mais qui
serait bien utile aussi sur un map.openstreetmap.fr



> Au passage, où traduire Grave pour 
> www.openstreetmap.org
>  (et
> d'autres) l'affichent correctement en français ?
>
>
Il me semble que c'est là:
https://translatewiki.net/wiki/Translating:OpenStreetMap

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouveau Rendu des Tuiles France - partie 2

[Christian Quest]

Le 18 août 2013 21:53, Philippe Verdy  a écrit :

> D'ailleurs le serveur effectue déjà un traitement graphique (ave nécessité
> de recompresser l'image produite) pour retourner des tuiles unitaires
> qu'ils stocke sous forme de métatuiles plus grandes, et je ne vois même pas
> pourquoi il ne peut pas retourner directement une "métatuile" entière
> directement sans aucun calcul.
>

Sais-tu au moins ce que contient une "métatuile" ?
As-tu regardé le code de mod_tile/renderd pour vérifier avant de poster ton
message ?

Une métatuile c'est à peu de chose près équivalent à un MBtiles (SQlite mis
à part)... ça contient des tuiles PNG de 256x256 pixels !
Et heureusement car sinon à chaque demande de tuile, il faudrait
décompresser la metatuile de 2048x2048 pour recompresser un extrait de
256x256...

Un peu de lecture pour le confirmer :
https://github.com/openstreetmap/mod_tile/blob/master/src/gen_tile.cpp#L227

CQFD
-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouveau Rendu des Tuiles France - partie 2

[Philippe Verdy]

Non on ne parle pas de la même chose: les métatuiles ne sont pas celles
servies aux clients (accès en lecture à la base du serveur de tuiles), mais
celles servies par les moteurs de rendu, qui sont beaucoup plus grosses (et
quand un serveur de rendu calcule une métatuile il va donc stocker
simultanément, ou de façon quasi-séquentielle, plusieurs tuiles juxtaposées.
La solution actuelle n'est pas optimale. Même si MBTtiles a été développé
comme une solution simple permettant de gérer efficacement la concurrence
d'accès en lecture, elle n'est pas efficace du côté de l'accès en écriture
par les serveurs de rendus (qui en font un usage quasi-séquentiel).
Je parlais bien d'un format de fichier de grosse image car c'est de ça dont
il s'agit : même s'il y a une surcouche SQLLite, la base reste dans un gros
fichier unique (avec des accès concurrents nombreux et aléatoires en
lecture, mais séquentiels en écriture).
Ce format n'est pas adapté à une utilisation sur autre chose qu'un serveur
de tuiles avec de nombreux accès clients concurrents. Il n'est pas efficace
sur une utilisation embarquée (où presque tous les accès seront
quasi-séquentiels avec très peu ou pas de concurrence.
Je dirais que MBTiles est une solution intérimaire en attendant de
développer quelquechose de mieux. Mais il n'est même pas efficace non plus
en terme d'espace de stockage (là encore un problème pour une solution
embarquée comme un navigateur mobile avec GPS). il est également couteux en
énergie (autonomie) et CPU (la surcouche SQLite, même si elle est plus
légère qu'un serveur SQL de premier plan, a un coût aussi).
Sincèrement je pense qu'on peut faire nettement mieux mais que la solution
n'a pas encore été développée ni tunée comme il le devrait. En attendant
MBTiles/SQLite n'est pas la panacée et ne répond pas à toute une série de
demandes et n'exploite pas au mieux les ressources qu'on a. Même la partie
HTTP du serveur de tuile n'est pas optimale (l'utilisation de domaines
multiples, au lieu d'utiliser le pipelining HTTP, est coûteuse sur les
caches HTTP en aval, cela limite les possibilités de déploiement par
proxies, et cela impose alors des restrictions d'usage beaucoup plus
strictes que ce qu'on pourrait faire).
Au final, les serveurs de tuiles ne savent pas monter en échelonnabilité,
les usages limités vont aussi limiter la valeur ajoutée apportées par ce
service, ce qui a en fin de compte un effet pervers sur la facilité
d'accroitre les ressources par l'obtention de nouveaux moyens. Victime du
succès, le service sature, et finalement se fait déborder. Ces restrictions
d'usage sont finalement nuisibles au long terme pour le projet qui doit
pourtant continuer à croitre ou bien s'étendra de lui-même faute de moyens.


Le 18 août 2013 22:27, Christian Quest  a écrit :

> Le 18 août 2013 21:53, Philippe Verdy  a écrit :
>
>> D'ailleurs le serveur effectue déjà un traitement graphique (ave
>> nécessité de recompresser l'image produite) pour retourner des tuiles
>> unitaires qu'ils stocke sous forme de métatuiles plus grandes, et je ne
>> vois même pas pourquoi il ne peut pas retourner directement une "métatuile"
>> entière directement sans aucun calcul.
>>
>
> Sais-tu au moins ce que contient une "métatuile" ?
> As-tu regardé le code de mod_tile/renderd pour vérifier avant de poster
> ton message ?
>
>  Une métatuile c'est à peu de chose près équivalent à un MBtiles (SQlite
> mis à part)... ça contient des tuiles PNG de 256x256 pixels !
> Et heureusement car sinon à chaque demande de tuile, il faudrait
> décompresser la metatuile de 2048x2048 pour recompresser un extrait de
> 256x256...
>
> Un peu de lecture pour le confirmer :
> https://github.com/openstreetmap/mod_tile/blob/master/src/gen_tile.cpp#L227
>
> CQFD
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> 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] Nominatim : type d'objets OSM retrouvés

[Yves Pratter]

> C'est bien la réponse la plus pertinente !
> Je l'avais remarqué en ajoutant celle de Jim Morrison au père Lachaise.
> 
> Tu parle de la présentation de la recherche Nominatim sur 
> tile.openstreetmap.fr ?
Je parlais effectivement de la présentation, pas du résultat ;-)

> C'est super basique, toute l'interface est brute de décoffrage 
> essentiellement destinée à consulter les tuiles des différents rendu (d'où 
> son nom "tile"), pas vraiment à fournir un service plus aboutit... mais qui 
> serait bien utile aussi sur un map.openstreetmap.fr
Oui, cette page (plus aboutie ?) serait effectivement pratique :-)

> Il me semble que c'est là: 
> https://translatewiki.net/wiki/Translating:OpenStreetMap
Merci pour le lien.

Je ne suis pas à l'aise avec cet outil : j'ai trouvé Grave yard ici :
https://translatewiki.net/w/i.php?title=Special%3ASearchTranslations&query=Osm%3AGeocoder.search+osm+nominatim.prefix.amenity.grave+yard

mais pas yard. C'est un oubli dans la version anglaise, ou ce mot se trouve 
ailleurs dans translatewiki.net ?

--
Yves

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

Re: [OSM-talk-fr] Amélioration rendu "FR" sur les zooms faibles...

[Christophe Merlet]

Le 18/08/2013 20:55, Philippe Verdy a écrit :




Le 18 août 2013 16:13, Christian Quest mailto:cqu...@openstreetmap.fr>> a écrit :


Au choix: fraises, groseilles, framboise, rhubarbe-banane, abricots,
toutes faites maison et siglées "OpenStreetMap" ;)


Question goût, que dire de "rhubarbe-banane" ?

[...]

 variantes épicées possibles aussi avec l'anis

étoilé (moulu et entier) ou la cardamome.



Je suis déçu que ton message soit si court sur un sujet que tu n'avais 
jamais étalé (comme la confiture) sur la liste...
Après tout le sujet est vaste, et tu aurais pu continuer à disserter sur 
l’intérêt d'utiliser une bassine en cuivre pour la cuisson, de rajouter 
ou non de la pectine, le type de sucre à utiliser (glucose, fructose ou 
saccharose). Comment stériliser et conserver les pots pendant des années...


J'ai confiance en toi, je sais que tu es capable de développer le sujet...


Librement,
--
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Amélioration rendu "FR" sur les zooms faibles...

[Philippe Verdy]

C'est surtout en voyant le mélange banane-rhubarbe proposé. C'est peut-être
à ton goût mais je doute fortement de l'intérêt de la recette, sauf si
c'est pour faire une compote pour bébés (pas besoin de longue cuisson).
Ceci dit ce n'est pas moi qui ai lancé le sujet. Mais puisqu'on en était à
proposer ses recettes de confitures... la confiture est faite pour être
étalée.


Le 18 août 2013 23:13, Christophe Merlet  a écrit :

> Le 18/08/2013 20:55, Philippe Verdy a écrit :
>
>>
>>
>>
>> Le 18 août 2013 16:13, Christian Quest > > a écrit :
>>
>>
>>
>> Au choix: fraises, groseilles, framboise, rhubarbe-banane, abricots,
>> toutes faites maison et siglées "OpenStreetMap" ;)
>>
>>
>> Question goût, que dire de "rhubarbe-banane" ?
>>
> [...]
>
>
>  variantes épicées possibles aussi avec l'anis
>
>> étoilé (moulu et entier) ou la cardamome.
>>
>
>
> Je suis déçu que ton message soit si court sur un sujet que tu n'avais
> jamais étalé (comme la confiture) sur la liste...
> Après tout le sujet est vaste, et tu aurais pu continuer à disserter sur
> l’intérêt d'utiliser une bassine en cuivre pour la cuisson, de rajouter ou
> non de la pectine, le type de sucre à utiliser (glucose, fructose ou
> saccharose). Comment stériliser et conserver les pots pendant des années...
>
> J'ai confiance en toi, je sais que tu es capable de développer le sujet...
>
>
> Librement,
> --
> Christophe Merlet (RedFox)
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] 19 août, journée mondiale de l'aide humanitaire, cartographie de Khartoum

[Severin MENARD]

Bonjour,

Le 19 août est la journée mondiale de
l'humanitaire
.

Dans le cadre de cet événement nous vous proposons de participer à la
cartographie à distance des zones les plus inondées de Khartoum au Soudan.
Plus d'informations sur la page wiki OSM, désormais aussi en français :
http://wiki.openstreetmap.org/wiki/FR:2013_Sudan_floods

Il y a trois jobs du Tasking Manager (gestionnaire de tâches) qui sont
d;evolu à cette réponse de crise :

   - no 289  où il reste quelques dalles
   avec des rues et bâtiments à cartographier
   - no 292  qui couvre une zone au
   sud-est de la ville ; sules les rues sont cartographiées dans cette
   première étape
   - no 293  qui comprend une grande
   partie des quartiers à l'ouest du fleuve où seules rues sont à
   cartographier compte tenu de la surface


Merci d'avance à tous les participants !

Séverin


2013/8/16 Severin MENARD 

> Bonsoir à tous,
>
> Merci à tous ceux qui ont participé à la cartographie sur le job du
> Tasking Manager. Le travail est pratiquement déjà achevé.
> J'ai ajouté deux autres jobs que vous pouvez trouver dans la page wiki :
> http://wiki.openstreetmap.org/wiki/2013_Sudan_floods. Pour visualiser
> facilement l'étendue de la zone habitée sur la partie Ouest de la ville,
> j'ai ajouté la zone résidentielle dans OSM :
> http://www.openstreetmap.org/#map=11/15.6776/32.4622
>
> Compte tenu de leur étendue, dans un premier temps, il s'agit de
> cartographier les rues.
>
> Bien cordialement,
>
> Severin
>
> HOT (Humanitarian OpenStreetMap Team)
>
>
> 2013/8/10 Severin MENARD 
>
>> Bonsoir à tous,
>>
>> Khartoum, la capitale du Soudan, subit depuis début août de très fortes
>> pluies qui donne lieu à des inondations et des zones totalement sous les
>> eaux, faisant déjà plusieurs victimes. Les prévisions météorologiques
>> annoncent un maintien des conditions météorologiques. Vous pouvez suivre
>> l'évolution de la situation sur khartoumflood.crowdmap.com.
>>
>> La réponse humanitaire est coordonnée sur le terrain par le PNUD.
>>
>> J'ai créé un premier job du Gestionnaire de tâches de HOT (*OSM Tasking
>> Manager*) afin de coordonner la cartographie des quartiers de Marabee El
>> Shareif et Soba East: http://tasks.hotosm.org/job/289. D'autres
>> quartiers viendront. Je vais aussi créer bientôt une page wiki.
>>
>> SVP cartographiez tous les rues et bâtiments de la zone du job afin
>> d'obtenir la situation pré-crise, sur laquelle une analyse des dommages
>> sera effectuée. La donnée OSM sur Khartoum est téléchargeable dans
>> différents formats SIG à partir du service HOT Export ; j'y ai configuré ce
>> job : http://export.hotosm.org/en/jobs/4233.
>>
>> Pour ceux qui ne connaissent pas le Tasking Manager (pas encore traduit
>> en français malheureusement), il suffit de cliquer sur l'onglet Task et de
>> sélectionner une case dans la carte, qui vous est alors réservée pour les
>> deux prochaines heures. Si la case vous semble trop grosse pour le temps
>> que vous avez à consacrer pour cartographier, vous pouvez la diviser en
>> quatre en cliquant sur Split it.
>>
>> Cliquez ensuite sur votre éditeur préféré. Pour JOSM, il faut que la
>> fonction télécommande soit activée dans les préférences et que JOSM soit
>> déjà ouvert.
>>
>> Une fois la tâche faite, vous retournez sur la page du *Tasking Manager* et
>> cliquez sur Mark task as done (vous pouvez ajouter un commentaire dans la
>> zone jsute au-dessus si besoin). La case apparaît alors en rouge.
>>
>>
>> Merci à celles et ceux qui participeront !
>>
>> Bien cordialement,
>>
>>
>> Séverin
>>
>> HOT (Humanitarian OpenStreetMap Team)
>>
>>
>>
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Circuits vélotourisme en Vaucluse

[Tony Emery]

Bonjour à tous,

Comme vous le savez peut-être déjà, la ville d'Orange vient de se doter de 3
circuits de vélotourisme. En accord avec l'office de tourisme, j'ai donc
réalisé des plans à inclure dans la publication faite par le Conseil Général
de Vaucluse et, comme vous vous en doutez, ces plans sont réalisé sous
OpenStreetMap.

Voici donc les documents concernant les 3 circuits avec les plans OSM
intégrés. Je penses que les autres circuits vont aussi basculer vers OSM.

De la Pierre aux Galets (Orange-Châteauneuf du Pape)

  

D'Orange à Caderousse

  

Paysages de Jean-Henri Fabre

  

Bonne lecture



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Circuits-velotourisme-en-Vaucluse-tp5773991.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Nominatim : type d'objets OSM retrouvés

[David Crochet]

Bonjour

Le 18/08/2013 23:09, Yves Pratter a écrit :

Je ne suis pas à l'aise avec cet outil : j'ai trouvé Grave yard ici :
https://translatewiki.net/w/i.php?title=Special%3ASearchTranslations&query=Osm%3AGeocoder.search+osm+nominatim.prefix.amenity.grave+yard

mais pas yard. C'est un oubli dans la version anglaise, ou ce mot se
trouve ailleurs dans translatewiki.net  ?


Translatewiki ne propose qu'ne traduction que si les concepteur du 
logiciel mettent un mot, un terme, une expression, un message autorisé à 
la traduction. Si "Yard" n'est pas traduisible, c'est que l'on ne pourra 
pas le traduire.


Cordialement

--
David Crochet

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