Re: [OSM-talk-fr] Montrer dans OSM les toponymes réels dans les différentes langues de la République française

[marc marc]

Le 03. 01. 18 à 22:19, Christian Rogel a écrit :
> Donner le nombre de name:X et de valeurs permet de relativiser les 
> tronçonnement des voies.

c'est une bonne idée de se baser sur le nombre de valeur différente
pour faire les stats.

ceci dit, sur le fond (avoir des contributeurs pour introduire 27 
langues dans osm), je me demande si le processus n'est pas 
fondamentalement inefficace.
On a vu à mainte reprise les dégâts que cela provoque régulièrement.
ne serrait-il pas plus intéressant de commencer par les objets osm qui 
ont un lien wikipedia/data en introduisant leur nom sur wikidata.
je ne suis pas un partisan inconditionnel de wikidata.
mais dans ce cas précis cela aurait les avantages :
- d'utiliser les infos déjà existante
- d'éviter d'avoir plusieurs projet qui font le même travail
- de monter en qualité.
au lieu de faire un processus manuel, il pourrait y avoir un import de 
qualité (vérifier que l'objet osm a le même nom que celui de wikidata 
(pour éviter de mettre à jour les nombreux village ou lieu-dit qui ont 
erronément le wikipedia/data de leur commune, ce qui pourrait remonter 
en anomalie).
si le nom osm match avec wikipedia/data, on importe le(s) name:xx 
pertinents selon la zone concernée.
le même code (par exemple dans osmose) pourrait servir à détecter les 
vandales, les erreurs et les futurs ajouts.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BANO / Cadastre différence nom de voie

[Christian Quest]

Effectivement, bravo Sherlock ! :)

Le 3 janvier 2018 à 21:31, Francois Gouget  a écrit :

> On Wed, 3 Jan 2018, Christian Quest wrote:
>
> > Sur le plan cadastral, il y a des libellés qui peuvent être différents de
> > ceux qu'on trouve dans FANTOIR... même si les deux sources sont la DGFiP.
> >
> > Là, il n'y a que le terrain qui peut servir à départager ces
> incohérences.
>
> Pas tout à fait. Wikipedia est très utile pour pas mal de ces
> incohérences. En l'occurrence on découvre que :
>
> * Hongerford est grosso-modo inconnu au bataillon.
>
> * Hungerford est une bourgade Anglaise qui est jumelée avec Ligueil, la
>   ville où ce trouve cette voie !
>   https://fr.wikipedia.org/wiki/Hungerford
>
> * Et la page anglaise de Ligueil confirme ce jumelage (mais rien sur la
>   page française).
>   https://en.wikipedia.org/wiki/Ligueil
>
> Donc, indépendamment de ce qui est écrit sur les panneaux, il y a de
> très fortes chances qu'Hungerford soit le nom correct.
>
>
> --
> Francois Gouget   http://fgouget.free.fr/
>Be careful of reading health books, you might die of a misprint.
>  -- Mark Twain
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] BANO / Cadastre différence nom de voie

[marc marc]

Le 03. 01. 18 à 21:31, Francois Gouget a écrit :
> On Wed, 3 Jan 2018, Christian Quest wrote:
> 
>> Sur le plan cadastral, il y a des libellés qui peuvent être différents de
>> ceux qu'on trouve dans FANTOIR... même si les deux sources sont la DGFiP.
>>
>> Là, il n'y a que le terrain qui peut servir à départager ces incohérences.
> 
> Pas tout à fait. Wikipedia est très utile pour pas mal de ces
> incohérences. En l'occurrence on découvre que :
> 
> * Hongerford est grosso-modo inconnu au bataillon.
> 
> * Hungerford est une bourgade Anglaise qui est jumelée avec Ligueil, la
>ville où ce trouve cette voie !
>https://fr.wikipedia.org/wiki/Hungerford
> 
> * Et la page anglaise de Ligueil confirme ce jumelage (mais rien sur la
>page française).
>https://en.wikipedia.org/wiki/Ligueil
> 
> Donc, indépendamment de ce qui est écrit sur les panneaux, il y a de
> très fortes chances qu'Hungerford soit le nom correct.

il n'y hélas pas vraiment de nom correct :)
la commune peux évidement changer le nom pour qu'il corresponde à la 
ville anglaise.
d'ici là name=le terrain (alt_name=fantoir si on veux le rendre 
accessible aux moteur de recherche)
et ajouter la ref fantoir pour permettre le match.
cela évite d'avoir le chemin en inconnu dans la page des matchs 
fantoir<>osm et qui sait peut-être un jour avoir un processus pour 
remonter à qui de droit les incohérences (c'est beau de rêver)


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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[osm . sanspourriel]

Désolé, quand on a le bonheur d'habiter en zone littorale, on déplore ce 
bleu vide : le rendu Mapnik est tellement plus fin (merci Christian et Cie).


Pourtant sur le côté dynamique c'est sympa.

Dans un hebdo-OSM ce site avait été signalé.

Un fond de carte muette (on a) et des fonds par langue ou vectoriels 
pour les textes ça peut être un bon compromis.


Mais le problème n'est pas tant la taille car on peut admettre que les 
principales langues ont des communautés assez grandes pour avoir un 
serveur de tuile (comme OSM-FR et OSM-DE) l'ont. Que le serveur de la 
fondation qui sert les tuiles depuis la France soit en langue locale ou 
en FR si possible, ça ne change pas grand chose en terme de bande passante.


Ou qu'on aille chercher les tuiles chez l'assos locale (ici OSM FR).

Reste que bretzel ou baguette, les pictos sont sans doute aussi dans la 
couche à adapter (fr ou fr-FR).


Là, sans vectoriel ça craque rapidement. Sauf à dire fr=fr-FR et que 
fr-CA sera seulement sur le Canada.


Ou à faire du GRIB qui est un vectoriel qui se cache (grille).

Le 03/01/2018 à 10:42, Christian Quest - cqu...@openstreetmap.fr a écrit :
Rendu vectoriel... et mapcat est un très bel exemple de ce qu'on peut 
faire avec les données OSM + wikipédia.


Le 3 janvier 2018 à 10:40, Bruno > a écrit :


Le 03/01/2018 à 10:25, Marc Gemis a écrit :

Connaissez-vous https://www.mapcat.com ?
- OSM data
- clic gauche
- des noms en langue locale et Anglais.

m.

Je ne connaissais pas.
Pour le changement de langue et vu le choix important, j'imagine
qu'il n'y a pas un rendu par langage ? c'est quoi le mécanisme
technique ?

2018-01-02 23:32 GMT+01:00 marc marc
>:

Bonsoir,

Le 02. 01. 18 à 23:10, Cédric Frayssinet a écrit :

Quand on passe de GMaps à OpenStreetMap.org, je trouve
que l'on perd
beaucoup à ne pas pouvoir cliquer (avec le bouton gauche)

il est clair qu'un clic droit serrait beaucoup pratique et
intuitif.

- interroger les objets

petit raccourcit : afficher l'adresse
cela ne te propose souvent le bon objet.

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


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





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





--
Christian Quest - OpenStreetMap France


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


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

[OSM-talk-fr] Montrer dans OSM les toponymes réels dans les différentes langues de la République française

[Christian Rogel]

J’ai poursuivi les recherches et j’ai trouvé un minimum de 27 langues (ou 
géolectes) susceptibles d’être cartographiées dans la République française.
Certaines sont curieusement peu présentes comme le corse et surtout l’occitan 
(33 départements français).

Donner le nombre de name:X et de valeurs permet de relativiser les 
tronçonnement des voies. 

Liste des codes de langues mise à jour  avec nb de name:X et nb de valeurs au 
2-01-18 : 

Codes ISO 639
Arpitan > name:frp  190 ; 190
Basque > name:eu  2 424 ; 2 240
Breton > name:br  28 170 ; 18 861
Catalan > name:ca  5788 ; 5 561
Corse > name:co  206 ; 206
Créole guyanais > name:gyn
Créole martiniquais et créole guadeloupéen > gcf  540 ; 426
Créole réunionais > name:gcr  0
Flamand occidental > name:vls  38 ; 38
Francique > name:frk  0
Maoré (Mahorais) > name:swb  2
Normand > name:nrf  0 (code provisoire name:fr-x-norman à déclasser 11)
Occitan > name:oc   3 669 ; 3 669
Picard > name:pcd 40
Tahitien > name:ty  122 ; 81

Codes provisoires actifs
Franc-comtois > name:fr-x-fc 17
Gallo > name:fr-x-gallo 4

Codes provisoires proposés :
Angevin > name:fr-x-angevin
Berrichon > name:fr-x-ber
Bourbonnais > name:fr-x-bourbon
Bourguignon > name:fr-x-brg
Champenois > name:fr-x-cham
Lorrain > name:fr-x-lor
Orléanais > name:fr-x-orlean
Poitevin > name:fr-x-poit
Saintongeais > name:fr-x-saint
Tourangeau > name:fr-x-tour

Sources : Wikipedia, Taginfo et tables des codes ISO 639 




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

Re: [OSM-talk-fr] BANO / Cadastre différence nom de voie

[Francois Gouget]

On Wed, 3 Jan 2018, Christian Quest wrote:

> Sur le plan cadastral, il y a des libellés qui peuvent être différents de
> ceux qu'on trouve dans FANTOIR... même si les deux sources sont la DGFiP.
> 
> Là, il n'y a que le terrain qui peut servir à départager ces incohérences.

Pas tout à fait. Wikipedia est très utile pour pas mal de ces 
incohérences. En l'occurrence on découvre que :

* Hongerford est grosso-modo inconnu au bataillon.

* Hungerford est une bourgade Anglaise qui est jumelée avec Ligueil, la 
  ville où ce trouve cette voie !
  https://fr.wikipedia.org/wiki/Hungerford

* Et la page anglaise de Ligueil confirme ce jumelage (mais rien sur la 
  page française).
  https://en.wikipedia.org/wiki/Ligueil

Donc, indépendamment de ce qui est écrit sur les panneaux, il y a de 
très fortes chances qu'Hungerford soit le nom correct.


-- 
Francois Gouget   http://fgouget.free.fr/
   Be careful of reading health books, you might die of a misprint.
 -- Mark Twain___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagguer les cinémas "art & essai"

[osm . sanspourriel]

Nos messages ont dû se croiser car côté Wikipédia on a les mêmes références.
ref:FR:CNC          N°AUTO    12
~name     NOM ETABLISSEMENT    GEORGE V
devices? ECRANS    11
capacity ?              FAUTEUILS  1 666 (François capacity dans ce cas 
c'est bon où faudrait-il diviser par le nombre d'écrans ?)

(pour Osmose ?) CODE COMMUNE 75108
(pour Osmose ?)   COMMUNE    Paris 8me
cinema:art et cinema:art:FR et  ART ET ESSAI    NON

Pourquoi ces différences mineures ?
la clé globale c'est cinema et comme dit par Marc on la précise, donc 
cinema:art semble court et explicite.

Après on apporte une précision pour la France donc cinema:art:FR.
Art au singulier car on dit art film et art cinema.

Ça me semble plus logique donc plus simple.

Pour le brand, ce n'est pas une marque mais plutôt une affiliation et 
l'affiliation multiple est possible mais ni brand ni network ne le 
prévoient actuellement.

network:Europa_Cinemas=yes ?

Le 03/01/2018 à 09:53, Antoine Riche - antoine.ri...@ymail.com a écrit :
En anglais on parle de "arts cinema" 
(https://en.wikipedia.org/wiki/International_Confederation_of_Art_Cinemas), 
on pourrait utiliser arts=yes ou plus explicite arts_cinema=yes.


Il y a un numéro d'autorisation dans le fichier open data, on le met 
en ref:FR:CNC ?


De nombreuses salles Arts et Essai en Europe sont membres du réseau 
Europa Cinemas (http://www.europa-cinemas.org/), tant qu'à y être on 
pourrait les identifier avec brand=Europa Cinemas


Ce qui donne (pour les zélés) :
arts_cinema=yes (toute salle se réclamant Arts et Essai, avec ou sans 
label selon les pays)

ref:FR:CNC=
cinema:FR:art_essai=A|B|C|D|E  (salles classés par le CNC)
brand=Europa Cinemas (pour les salles du réseau)

La valeur no pour cinema:FR:art_essai ne me semble plus utile si on 
applique les autres tags, on aurait plutôt arts_cinema=no


Antoine.

Le 02/01/2018 à 23:24, marc marc a écrit :

Le 02. 01. 18 à 22:57,osm.sanspourr...@spamgourmet.com  a écrit :

Le 02/01/2018 à 21:10, George Kaplan -georgekaplan...@hotmail.fr  a écrit :

De façon similaire à school:FR, ça donne plutôt cinema:FR=art_essai .
Est-ce qu’il y a un terme du CNC pour les cinémas qui ne sont pas
« art et essai » ?


Oui, c'est dans la liste citée et ça s'appelle "NON";-).
Je propose simplement :
cinema:FR:art_essai=A|B|C|D|E|no

étant donné que chaque cinéma est susceptible de diffuser ce genre de
film, ne serrait-il pas intéressant d'essayer de trouver un nom de tag
anglais "parent" qui puisse s'appliquer "mondialement" sous la forme
cinema: =yes/no ?

avoir un tag commun permet un jour d'avoir un outil qui permet de
trouver un tel cinéma peu importe s'il se trouve à Roubais ou à Mons.

cela n’empêche pas d'avoir un tag :FR pour l'affinage de la
classification niveau français mais qui irait dans un sous-tag du tag
avec le mot anglais comme c'est la tradition dans osm.
par analogie, on utilise school:FR et non pas ecole:FR
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr




 
	Garanti sans virus. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


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


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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

Note: ton expérimentation utilisait le fichier des IRIS de 2013, ce n'est
pas vraiment le dernier en date, et le fichier de 2016 contient tous les
départements y compris l'outremer (sauf encore Mayotte dont la couverture
cadastrale en cours est encore loin d'être aboutie alors que les
changements y sont importants avec la hausse rapide de sa population)
Il est possible que les shapes de 2016 soit déjà plus précis que ce qu'ils
étaient dans l'édition de 2013 (basées sur les données collectées en 2012):
entre temps il y a eu beaucoup de communes vectorisées et plein de SIG
communaux ou intercommunaux se sont montés et ont gagné en puissance et
précision.

Le 3 janvier 2018 à 17:13, Vincent de Château-Thierry  a
écrit :

>
> > De: "Philippe Verdy" 
> >
> > Je n'ai jamais parlé pas d'importation directe mais bien
> > d'intégration (comme tout ce qui se fait dans OSM de toute façon!)
> > Ce n'est pas parce que le GéoFLA était imprécis qu'on n'a pas
> > intégré les limites communales à l'aide d'une meilleure source (le
> > cadastre malgré qu'il n'était même pas vectorisé en grande partie)
> > en faisant les conflations nécessaires et qu'on a cherché à
> > cependant respecter le même découpage que l'INSEE (et on n'a pas
> > atendu non plus que l'INSEE se mette à jour quand les communes ont
> > changé on avait fait le travail avant).
>
> On est d'accord. Le souci aujourd'hui, c'est qu'à la différence de
> l'épisode des limites communales, on n'a pas de source géométrique correcte
> pour les IRIS. Même sur Paris où tu proposes de tester, les limites passent
> trop souvent entre 2 rues, sans qu'on sache si c'est volontaire ou si en
> fait la vraie limite est sur une des deux, et juste rendue imprécise par la
> simplification géométrique de Contours. Donc je ne vois pas l'intérêt d'un
> test avec une donnée géométrique si brouillonne. J'avais tenté une
> conflation OSM-Contours IRIS [1] mais j'ai du la limiter aux contours de
> communes tant les découpages infra-communaux étaient approximatifs. Je n'ai
> pas l'impression que la qualité géométrique a changé depuis.
> Pour moi tant qu'on n'a pas résolu la question d'une source géométrique
> fiable et de licence compatible, le sujet de l'intégration, en test ou au
> complet, ne se pose pas. Le jour venu, je suis d'accord avec toi sur
> l'ampleur modeste du projet et donc notre capacité à le maintenir. Le choix
> des tags en partant de boundary=statistic serait un bon départ à mon avis.
>
> vincent
>
> [1] : https://www.data.gouv.fr/fr/datasets/decoupage-iris-
> combine-aux-limites-communales-openstreetmap/
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

Paris n'est pas le meilleure exemple j'en ai donné d'autres. Mais tester
c'est faire une démo quelque part où ça peut donner des bons résultats. On
a vu Rennes se lancer dans ce travail (ce n'est pas la commune la plus
simple). Mais il peut y avoir d'autres initiatives ailleurs.

On peut commencer doucement pour ensuite voir ces données exploitées dans
certaines villes et pousser les autres à suivre et demander à travailler
avec l'INSEE sur des données plus précises. Cela peut aussi inciter à avoir
une meilleure vue citoyenne sur la façon dont les découpages électoraux
sont faits (et ont souvent été critiqué pour le manque complet de
transparence et des soupçons de clientélisme dans les élections).
Les grands partis politiques qui contrôlaient les élections avant sont à la
ramasse, et le changement massif de majorité devrait pousser la majorité
actuelle à ne pas être accusée des mêmes maux du passé (il n'y a pas qu'un
président, mais aussi une majorité nouvelle née qui pourrait ne pas aimer
se faire simplement traiter comme des moutons dociles): les initiatives
locales pourraient pousser à aller de l'avant, surtout si cela vient de la
société civile (nous en sommes) afin d'éviter que se creuse davantage
l'écart.

On sait que des arbitrages douloureux vont avoir lieu sur plain de services
publics et que les idées de nouvelles taxes ne vont pas être appréciées.
Les communes sont à la peine et se voient limiter leurs budgets.
L'influence de l'Etat est moins forte, la société civile peut prendre un
pied en s'impliquant directement. Même les gros partis vont se reformer et
se restructurer en faisant plus confiance à la société civile (c'est leur
seule façon de continuer à exister et rester audible). L'heure est à la
transparence et l'initiative locale. Les communes n'attendent plus grand
chose de l'Etat ou de ses agences comme l'INSEE. Mais on n'est pas là pour
casser l'INSEE qui existera encore mais aura ses missions moins dépendantes
de l'Etat et plus à l'écoute des besoins locaux et des initiatives locales.
L'Insee pourrait se mettre à notre écoute et on peut aussi les aider
puisque l'Insee a autant de mal que nous à trouver des terrains de
collaboration avec l'IGN. Ces deux agences vont changer de voilure et de
façon de fonctionner de façon verticale et centralisatrice. L'Europe nous
pousse aussi à être innovant et cherche également à regagner la confiance
citoyenne (surtout depuis le chambardement du brexit).

Bref il y a de la place pour les collectivités locales qui au passage
peuvent aussi faire des économies d'échelle et aller vers plus de
coopérations sur des solutions ouvertes. Dans certaines communes il y a
aura reconnaissance du travail des assos locales et comités de quartiers et
redessiner les contours de la ville. On peut être un soutien (et pas que
nous, les assos caritatives aussi sont à la peine avec le désengagement de
l'Etat, et cherchent donc des collaborations transversales, y compris
internationales, pour regrouper des moyens, des équipes, faire des
expérimentations ici et là et développer de nouvelles solutions: l'Etat
suivra parce qu'il n'a pas vraiment le choix et ne peut pas se couper
davantage des collectivités locales à qui il demande beaucoup et de plus en
plus sans leur donner les moyens).

Alors regardons d'un peu plus près certains territoires qu'on pourraient
analyser: un nouveau tag c'est expérimental, et on pourra l'enrichir
ensuite d'un système de qualification et de validation. Le travail n'est
pas compliqué à amorcer dans plein de petites villes de province, et
l'initiative de Rennes peut aussi donner des pistes pour les autres et
passer ensuite à plus grande échelle pour obtenir la précision qui nous
manque et que l'Insee ne nous communique pas encore. Si on arrivait déjà à
couvrir 25% des villes (dont celles découpées en moins de 5-6 IRIS et
quelques grandes comme Rennes, le reste suivra, y compris Paris aussi qui
voudra ne pas rester en recul sur le mouvement qu'on appelle "la ville
intelligente" prenant en compte un découpage fin des territoires et des
besoins et une mesure fine et plus dynamique adaptée à d'autres besoins que
ceux actuellement encore traités par l'Insee).


Le 3 janvier 2018 à 17:13, Vincent de Château-Thierry  a
écrit :

>
> > De: "Philippe Verdy" 
> >
> > Je n'ai jamais parlé pas d'importation directe mais bien
> > d'intégration (comme tout ce qui se fait dans OSM de toute façon!)
> > Ce n'est pas parce que le GéoFLA était imprécis qu'on n'a pas
> > intégré les limites communales à l'aide d'une meilleure source (le
> > cadastre malgré qu'il n'était même pas vectorisé en grande partie)
> > en faisant les conflations nécessaires et qu'on a cherché à
> > cependant respecter le même découpage que l'INSEE (et on n'a pas
> > atendu non plus que l'INSEE se mette à jour quand les communes ont
> > changé on avait fait le travail avant).
>
> On est d'accord. Le souci aujourd'hui, c'est qu'à la différence de
> l'épisode 

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Antoine Riche]

Sympa ce Mapcat en effet. Manque juste un truc : le © Les contributeurs 
OpenStreetMap à côté du © Wikipédia. Même en version Beta c'est dommage...


Le 03/01/2018 à 10:42, Christian Quest a écrit :
Rendu vectoriel... et mapcat est un très bel exemple de ce qu'on peut 
faire avec les données OSM + wikipédia.


Le 3 janvier 2018 à 10:40, Bruno > a écrit :


Le 03/01/2018 à 10:25, Marc Gemis a écrit :

Connaissez-vous https://www.mapcat.com ?
- OSM data
- clic gauche
- des noms en langue locale et Anglais.

m.

Je ne connaissais pas.
Pour le changement de langue et vu le choix important, j'imagine
qu'il n'y a pas un rendu par langage ? c'est quoi le mécanisme
technique ?





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Samy Mezani]

Il y a aussi https://openmaptiles.org/ qui affiche les noms dans pas mal 
de langues.


Le lien est plutôt https://openmaptiles.org/languages/fr/

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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Samy Mezani]

Bonjour,

Le 03/01/2018 à 09:55, Bruno a écrit :
La carte est affichée dans la langue du pays par défaut, si je regarde 
la Russie ou la Pologne , et bien c'est inutilisable (pour moi)




Il y a aussi https://openmaptiles.org/ qui affiche les noms dans pas mal 
de langues.


Samy

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

Re: [OSM-talk-fr] Question sur le rendu standard !

[Christian Quest]

C'est visiblement un bug de mapnik et/ou de postgis pour calculer une
position au libellé sur le polygone.

Ce n'est pas lié directement à la feuille de style des rendus, mais aux
libraires sous-jacentes...

postgis propose 2 fonctions : ST_Centroid et ST_PointOnSurface

ST_Centroid ne garantit pas que le point est dans le polygone, et
ST_PointOnSurface garantit que le point est dans le polygone, mais pas
forcément là où naturellement on le mettrait

Un nouvel algo est apparu il y a peu pour calculer une position plus
naturelle, mais il n'est pas encore intégré à postgis ou mapnik à ce que je
sache.



Le 3 janvier 2018 à 16:50, althio  a écrit :

> >> Où fait-on remonter ce type de problème (si c'est bien un problème ?) ?
> >
> > ici https://github.com/gravitystorm/openstreetmap-carto/issues
> > et là https://github.com/cquest/osmfr-cartocss/issues
>
> En fait, cela doit déjà être connu :
> https://github.com/gravitystorm/openstreetmap-carto/issues/2428
> https://github.com/gravitystorm/openstreetmap-carto/issues/2511
> https://github.com/gravitystorm/openstreetmap-carto/issues/1465
>
> et voire "au-dessus", améliorations en cours dans les dernières
> versions de mapnik
> https://github.com/mapnik/mapnik/issues/3550
> https://github.com/mapnik/mapnik/issues/3558
> https://github.com/mapnik/mapnik/pull/3771
> https://github.com/mapnik/mapnik/pull/3811
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Contours des IRIS

[marc marc]

Le 03. 01. 18 à 16:42, Philippe Verdy a écrit :

> Ce n'est pas si gros que ça.

Il me semble erroné de parler d'intégration.
On peux pas dire à la fois qu'il y en a des milliers et que tu vas les 
intégrer seul à la main, on parle donc bien d'un import qui devra 
utiliser au maximum les objets actuels.

J'aimerai connaître :
- l'outil que tu vas utiliser pour rapprocher les limites libre 
imprécise de l'insee des frontières supposée exacte d'osm
- sur quelle base vas-tu décider où est le tracé exact entre 2 zone iris 
pour la partie du tracé qui ne suis pas une limite existante, par 
exemple lorsqu'il est entre 2 rues.
- un exemple de fichier .osm que tu veux importer sur par exemple une 
petite commune ayant 2 ou 3 iris.

> Pour le suivi des mises à jour on pourra encore utiliser les données INSEE

concrètement, comment cela se passe ?
quelle fréquence de changement ?
comment est publiée l'info de modif de tracé ?
l'ancien tracé est supprimé et un nouveau tracé avec un nouvel id voit 
le jour ?
ou un tracé peux être modifié et conserver le même id ?
quel outil qa pour suivre leur validité ? tu écris une analyse osmose ?

> Quel tag : boundary=statistic ?
+ ref:iris (admin_type et border_type ne conviennent pas selon moi)
sur la relation uniquement pour ne pas polluer des chemins avec des 
excès de tag redondant (d'autant + que tu dis que la majorités de ces 
chemins seront ceux des limites existantes)

Ceci dit, je pense qu'avant de vouloir faire des stats au niveau 
infra-communal pour comparer l'égalité des citoyens face aux infras 
publique (sic !), il faudrait avoir ces infras dans osm. quand on voit 
le nombre d'écoles manquantes, ce serrait pas un luxe de progresser sur 
ce point.
sinon la seule chose qu'on aura, c'est une surcouche qui affiche le 
contour dans iris sans aucune autre plus-value que son affichage.
Dans ce cas, un simple layer ou un umap fait tout aussi bien.

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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Vincent de Château-Thierry]

> De: "Philippe Verdy" 
> 
> Je n'ai jamais parlé pas d'importation directe mais bien
> d'intégration (comme tout ce qui se fait dans OSM de toute façon!)
> Ce n'est pas parce que le GéoFLA était imprécis qu'on n'a pas
> intégré les limites communales à l'aide d'une meilleure source (le
> cadastre malgré qu'il n'était même pas vectorisé en grande partie)
> en faisant les conflations nécessaires et qu'on a cherché à
> cependant respecter le même découpage que l'INSEE (et on n'a pas
> atendu non plus que l'INSEE se mette à jour quand les communes ont
> changé on avait fait le travail avant).

On est d'accord. Le souci aujourd'hui, c'est qu'à la différence de l'épisode 
des limites communales, on n'a pas de source géométrique correcte pour les 
IRIS. Même sur Paris où tu proposes de tester, les limites passent trop souvent 
entre 2 rues, sans qu'on sache si c'est volontaire ou si en fait la vraie 
limite est sur une des deux, et juste rendue imprécise par la simplification 
géométrique de Contours. Donc je ne vois pas l'intérêt d'un test avec une 
donnée géométrique si brouillonne. J'avais tenté une conflation OSM-Contours 
IRIS [1] mais j'ai du la limiter aux contours de communes tant les découpages 
infra-communaux étaient approximatifs. Je n'ai pas l'impression que la qualité 
géométrique a changé depuis.
Pour moi tant qu'on n'a pas résolu la question d'une source géométrique fiable 
et de licence compatible, le sujet de l'intégration, en test ou au complet, ne 
se pose pas. Le jour venu, je suis d'accord avec toi sur l'ampleur modeste du 
projet et donc notre capacité à le maintenir. Le choix des tags en partant de 
boundary=statistic serait un bon départ à mon avis.

vincent

[1] : 
https://www.data.gouv.fr/fr/datasets/decoupage-iris-combine-aux-limites-communales-openstreetmap/


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

Re: [OSM-talk-fr] Question sur le rendu standard !

[althio]

>> Où fait-on remonter ce type de problème (si c'est bien un problème ?) ?
>
> ici https://github.com/gravitystorm/openstreetmap-carto/issues
> et là https://github.com/cquest/osmfr-cartocss/issues

En fait, cela doit déjà être connu :
https://github.com/gravitystorm/openstreetmap-carto/issues/2428
https://github.com/gravitystorm/openstreetmap-carto/issues/2511
https://github.com/gravitystorm/openstreetmap-carto/issues/1465

et voire "au-dessus", améliorations en cours dans les dernières
versions de mapnik
https://github.com/mapnik/mapnik/issues/3550
https://github.com/mapnik/mapnik/issues/3558
https://github.com/mapnik/mapnik/pull/3771
https://github.com/mapnik/mapnik/pull/3811

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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

Je n'ai jamais parlé pas d'importation directe mais bien d'intégration
(comme tout ce qui se fait dans OSM de toute façon!) Ce n'est pas parce que
le GéoFLA était imprécis qu'on n'a pas intégré les limites communales à
l'aide d'une meilleure source (le cadastre malgré qu'il n'était même pas
vectorisé en grande partie) en faisant les conflations nécessaires et qu'on
a cherché à cependant respecter le même découpage que l'INSEE (et on n'a
pas atendu non plus que l'INSEE se mette à jour quand les communes ont
changé on avait fait le travail avant).

Ce n'est pas si gros que ça. Pour le suivi des mises à jour on pourra
encore utiliser les données INSEE des IRIS à titre de comparaison et pour
les rapprochements utiliser les identifiants INSEE en référence. L'INSEE
suivra alors, et on peut prendre de l'avance sur lui en nous basant sur des
efforts plus précoces et plus volontaristes des collectivités locales qui
veulent développer (et ont besoin) de maillage fin. L'INSEE fera ses études
à la demande des collectivité et suivra le cadre de travail qu'elles
définissent plus précisément. Elle fera ses statistiques sur cette base
même si en attendant elle ne publie pas les mises à jour précises de ses
IRIS. Mais l'INSEE ferait mieux de revoir sa politique de divulgation pour
éviter les simplifications géométriques (qui suffisent pour ses propres
cartes mais pas pour nous qui voudrions des cartes plus précises à la
portée de ce que voient réellement les citoyens concernés).

On en a déjà parlé concernant le zonage électoral : les arrêtés
préfectoraux ou ministériels sont insuffisants. La presse locale
s'intéresse à des zonages précis que l'INSEE ou le ministère de l'Intérieur
ne fournit toujours pas. C'est pourtant essentiel de savoir pour un citoyen
s'il est ou pas concerné réellement par une politique locale ou un
aménagement et où il peut agir (ou militer en cas de besoin de changement).

C'est pour ça que j'ai demandé quels tags on pourrait utiliser, pour
commencer dans quelques villes et ensuite développer les méthodes plus
systématiques pour achever ça: ce n'est pas insurmontable, cela concerne
des villes où on a déjà des données très précises et on a déjà les autres
découpages administratifs pour nous aligner dessus.

A titre d'expérience initiale on peut éviter de commencer par Paris (mais
dont les IRIS découpent les arrondissements et reprennent aussi les limites
des grands quartiers et sous-quartiers administratif: l'expérience peut
être tentée déjà dans un sous-quartier, étendu ensuite à tout le quartier,
puis l'arrondissement). ceci fait on pourra voir si le découpage électoral
colle lui aussi réellement (ce qui devrait être le cas normalement puisque
la loi impose l'équité des résidents  selon les règles de représentation
avec pas plus de 20% d'écart de représentation selon les décisions du
Conseil constitutionnel et que ce découpage doit s'appuyer sur la
population légale connue à une date donnée, celle utilisée par l'INSEE
justement à partir des IRIS utilisés pour ses enquêtes).

Pas mal de communes sont simples à faire avec seulement deux ou 3 IRIS, et
certains départements n'ont que 3 communes découpées.

Bref je repose la question à laquelle personne ne veut répondre. Quel tag :
boundary=statistic ?

Le 3 janvier 2018 à 15:58, Vincent de Château-Thierry  a
écrit :

> Bonjour,
> et heureuse année 2018 :)
>
> On peut considérer les IRIS comme de peu d'intérêt, mais ils restent un
> outil d'analyse auquel sont rattachés pas mal de stats [1], que ça plaise
> ou non. L'IGN continue (pour combien de temps ?) de commercialiser leur
> découpage recalé sur la BD Topo [2]. Bref, ils sont encore dans le paysage
> géomatique pour quelques temps...
> Partant de là, je trouve pertinent qu'on cherche à disposer de leurs
> limites dans OSM, ne serait-ce que pour avoir via la même base le moyen de
> géocoder des ressources ET de les sectoriser en IRIS. Difficile d'avoir une
> cohérence géométrique avec des contenus maintenus séparément. Et comme
> d'habitude, on n'a pas à préjuger de qui s'en servira.
> Le bémol, déjà souligné plus tôt dans ce fil, c'est la qualité géométrique
> des IRIS OSM-compatibles en terme de licence. Il s'agit du débat qu'on a eu
> au moment de la libération du GeoFLA il y a 5 ans : la donnée sémantique
> nous intéressait, mais la précision géométrique était incompatible avec
> OSM, donc on n'a pas formellement intégré le GeoFLA. C'est pareil
> aujourd'hui avec les IRIS : en l'état je ne suis pas pour utiliser la
> géométrie des IRIS de Contours-IRIS, ce serait une juxtaposition de données
> plus qu'une intégration.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question sur le rendu standard !

[althio]

> Bonjour et bonne année à toutes et tous !

Itou à toutes et itou à tous :)

> dans le rendu carto standard (et fr), le name s'affiche parfois de façon 
> "décalé".

Tout cela est bien bizarre en effet, sacré pioche.

> Où fait-on remonter ce type de problème (si c'est bien un problème ?) ?

ici https://github.com/gravitystorm/openstreetmap-carto/issues
et là https://github.com/cquest/osmfr-cartocss/issues

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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Vincent de Château-Thierry]

Bonjour,
et heureuse année 2018 :)

> De: "Philippe Verdy" 
> 
> Je ne vois pas en quoi c'est "inutile".
> 
> Le 3 janvier 2018 à 13:44, Christian Quest < cqu...@openstreetmap.fr
> > a écrit :
> 
> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
> mieux ils sont malheureusement encore trop utilisés. Ils sont de
> taille communale la plupart du temps et pas à jour ailleurs.
> 
> Ils ne sont réellement utiles que pour projeter des statistiques
> réalisées par l'INSEE avec ce maillage, pour le reste, je ne vois
> pas trop.
> 
> Dans les quartiers où la population a changé, c'est sûr que ça ne
> représente plus grand chose de significatif, y compris les stats si
> elles n'ont pas été remises à jour par une enquête de terrain
> complète.

On peut considérer les IRIS comme de peu d'intérêt, mais ils restent un outil 
d'analyse auquel sont rattachés pas mal de stats [1], que ça plaise ou non. 
L'IGN continue (pour combien de temps ?) de commercialiser leur découpage 
recalé sur la BD Topo [2]. Bref, ils sont encore dans le paysage géomatique 
pour quelques temps...
Partant de là, je trouve pertinent qu'on cherche à disposer de leurs limites 
dans OSM, ne serait-ce que pour avoir via la même base le moyen de géocoder des 
ressources ET de les sectoriser en IRIS. Difficile d'avoir une cohérence 
géométrique avec des contenus maintenus séparément. Et comme d'habitude, on n'a 
pas à préjuger de qui s'en servira.
Le bémol, déjà souligné plus tôt dans ce fil, c'est la qualité géométrique des 
IRIS OSM-compatibles en terme de licence. Il s'agit du débat qu'on a eu au 
moment de la libération du GeoFLA il y a 5 ans : la donnée sémantique nous 
intéressait, mais la précision géométrique était incompatible avec OSM, donc on 
n'a pas formellement intégré le GeoFLA. C'est pareil aujourd'hui avec les IRIS 
: en l'état je ne suis pas pour utiliser la géométrie des IRIS de 
Contours-IRIS, ce serait une juxtaposition de données plus qu'une intégration. 

vincent

[1] : https://www.insee.fr/fr/statistiques?debut=0=ICQ-1
[2] : http://professionnels.ign.fr/irisge

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

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

@althio: Merci pour le lien ! J'ai rajouté mon petit commentaire mais sans
trop d'espoir puisque le ticket a déjà été clôturé :(

@Jo: Oui le rendu sur hikebikemap.org est pas mal mais perso je préfère
opentopomap.org pour un zoom < 9 et opensnowmap.org pour un zoom > 9.


Le 3 janvier 2018 à 14:59, althio  a écrit :

> Non tu n'es pas le seul, il suffit d'aller voir la question sur :
> https://github.com/gravitystorm/openstreetmap-carto/issues/2931
>
> -- althio
>
>
> 2017-12-28 15:10 GMT+01:00 Vincent Frison :
> > Hello,
> >
> > Je sais pas si je suis le seul mais pour moi les cartes affichant le
> relief,
> > c'est à dire avec hillshade et/ou courbes de niveaux, sont bien plus
> jolies
> > que celles sont relief. Je dirais même qu'en plus d'être plus jolies
> elles
> > sont beaucoup plus claires car elles permettent de se repérer plus
> > facilement avec le relief.
> >
> > Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et
> je
> > trouve ça plus que dommage.
> >
> > Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> > comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le
> problème
> > c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses
> fonctionnalités
> > (principalement celle qui permet de chercher les objets afin de voir tous
> > les détails).
> >
> > Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement
> le
> > relief est assez mal rendu et puis surtout il est vraiment orienté pour
> les
> > vélos en masquant la plupart des informations pour mettre en valeur
> celles
> > utiles aux cyclistes.
> >
> > J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> > relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une
> option
> > pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
> petites
> > checkboxes en plus de celles existantes (permettant d'afficher les notes
> de
> > carte, etc.).
> >
> > Sur le site http://opensnowmap.org en allant dans les settings on peut
> > afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> > l'impression que c'est juste un layer supplémentaire (avec hillshade et
> > courbes de niveaux) qui s'affiche en plus de celui du rendu standard..
> mais
> > qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
> valeur
> > ajoutée est vraiment énorme !
> >
> > Suis je le seul à qui ça manque ?
> >
> > Et à qui devrais  je demander cette évolution ? Sur un mailing list
> > particulière ou directement en créant une issue ici:
> > https://github.com/gravitystorm/openstreetmap-carto ?
> >
> > Merci, Vincent.
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

Certes les données géographiques de l'INSEE sont améliorables (merci à la
Métropole de Rennes de vouloir les définir plus précisément elle-même:
l'INSEE suivra car à ce niveau elle est obligée de s'accorder avec les
collectivités locales). L'INSEE publiera donc des mises à jour pour chaque
ville qui s'y mettra (et rien n'empêche une ville de développer un maillage
encore plus fin, si elle en a la capacité et les moyens).
Je ne crois pas du tout que c'est un "pis aller", c'est une base
essentielle de travail, le minimum exigé par la loi actuelle (qui évoluera
pour tenir compte des besoins et si les citoyens l'exigent pour comprendre
les décions prises sur leur territoire).

On a tout à gagner à rendre ce maillage visible, public, auditable par les
citoyens de base et pas seulement soumis aux manipulations de quelques
élites qui peuvent décider de les trafiquer pour des raisons électoralites
voire clientélistes: tout changement à ce maillage doit être détectable,
contrôlable par tous (pour éviter des manipulations locales consistant à
ajouter tel ou tel immeuble ou en retirer un autre pour masquer
statistiquement une opération prévue et faire croire que cela n'aura pas
d'impact négatif.

A l'heure où des tas de services publics sont remaniés administrativement
et ferment du jour au lendemain sans aucune concertation ni consultation
publique mais juste des explications données après coup sur des
statistiques manipulées, il serait bon de savoir qu'il y a une réelle
égalité de traitement des citoyens et le respect de l'équité (relative) des
droits pour que ne s'arrête la création de territoires exclus des
politiques publiques (mais qui doivent pourtant payer pour les autres
territoires voisins qui sont les seuls à bénéficier des efforts publics et
sinon subir des temps de transport ou payer plus cher l'accès aux services
de proximité parce qu'ils ne font plus partie du territoire visé par un
aménagement public ou n'en subiront que les nuisances).

La statistique c'est l'instrument de base de l'exercice du pouvoir de
l'autorité publique. Elle justifie tout, mais doit la statistique elle-même
se justifier et correspondre à la définition et l'usage des territoires par
ceux qui y vivent réellement.

Les IRIS ne sont pas les seuls indicateurs, on a aussi les PLU, les PDU où
figurent des tas de décisions contestables... mais pas contestées car
masquées ou rendues incompréhensibles et non auditables par le commun des
mortels à qui on ne fournit que des données très vagues. L'INSEE a du
travail à faire pour rendre ses découpages fins réellement conformes à la
réalité : ce découpage devrait être aussi exact que ce qui existe dans les
SIG des communes et administrations : on nous DOIT cette information selon
la loi française elle-même (et aussi les directives européennes INSPIRE qui
tardent encore à s'imposer à nos gouvernants).

Le 3 janvier 2018 à 11:51, REBOUX Maël  a
écrit :

> Bonjour,
>
>
>
> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
> mieux ils sont malheureusement encore trop utilisés. Ils sont de taille
> communale la plupart du temps et pas à jour ailleurs.
>
> Nous sommes un certain nombre de « grosses » collectivités territoriales à
> avoir réclamer à l’INSEE il y a déjà qqs années maintenant une mise à jour
> de ces limites, notamment dans les zones « dynamiques » (à l’urbanisation
> qui bouge vite et donc où la population croît). L’INSEE n’a pas accédé à
> nos demandes ce qui fait que ces maillages sont obsolètes sur les zones qui
> en auraient besoin.
>
>
>
> Nous en sommes rendus à publier des mises à jour locales plus à jour des
> réalités du terrain. Exemple : https://public.sig.
> rennesmetropole.fr/geonetwork/srv/fre/catalog.search#/
> metadata/df789a3f-9980-4629-95be-50a8b04eac3c
>
>
>
> *Dans un souci de mise en adéquation des contours des différents zonages
> de gestion (quartier, périmètres électoraux...), Rennes Métropole a procédé
> à une numérisation des Iris en se basant sur des référentiels internes. Du
> fait de l'évolution des communes depuis la mise en œuvre des Iris, certains
> contours ont été revus en conséquence. De ce fait, cette couche n'est pas
> la couche officielle fournie par l'Insee (cf la description de la
> généalogie).*
>
>
>
> Cdt,
>
>
>
> *Maël REBOUX*
> Service Information Géographique Rennes Métropole
> Chargé de mission "diffusion"
>
> 02 99 86 63 71
>
> Twitter : @mael_reboux_ig 
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Jo]

http://hikebikemap.org/ montre le reliëf d'une très belle façon et il y a
moyen de visualiser beaucoup d'itinéraires. Je pense que cyclemap le fait
aussi.

Polyglot


2018-01-03 14:59 GMT+01:00 althio :

> Non tu n'es pas le seul, il suffit d'aller voir la question sur :
> https://github.com/gravitystorm/openstreetmap-carto/issues/2931
>
> -- althio
>
>
> 2017-12-28 15:10 GMT+01:00 Vincent Frison :
> > Hello,
> >
> > Je sais pas si je suis le seul mais pour moi les cartes affichant le
> relief,
> > c'est à dire avec hillshade et/ou courbes de niveaux, sont bien plus
> jolies
> > que celles sont relief. Je dirais même qu'en plus d'être plus jolies
> elles
> > sont beaucoup plus claires car elles permettent de se repérer plus
> > facilement avec le relief.
> >
> > Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et
> je
> > trouve ça plus que dommage.
> >
> > Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> > comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le
> problème
> > c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses
> fonctionnalités
> > (principalement celle qui permet de chercher les objets afin de voir tous
> > les détails).
> >
> > Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement
> le
> > relief est assez mal rendu et puis surtout il est vraiment orienté pour
> les
> > vélos en masquant la plupart des informations pour mettre en valeur
> celles
> > utiles aux cyclistes.
> >
> > J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> > relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une
> option
> > pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
> petites
> > checkboxes en plus de celles existantes (permettant d'afficher les notes
> de
> > carte, etc.).
> >
> > Sur le site http://opensnowmap.org en allant dans les settings on peut
> > afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> > l'impression que c'est juste un layer supplémentaire (avec hillshade et
> > courbes de niveaux) qui s'affiche en plus de celui du rendu standard..
> mais
> > qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
> valeur
> > ajoutée est vraiment énorme !
> >
> > Suis je le seul à qui ça manque ?
> >
> > Et à qui devrais  je demander cette évolution ? Sur un mailing list
> > particulière ou directement en créant une issue ici:
> > https://github.com/gravitystorm/openstreetmap-carto ?
> >
> > Merci, Vincent.
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

C'est pourtant la base des stats officielles et la source du découpage
administratif ou électoral. C'est essentiel aussi pour comprendre comment
ça marche et ensuite avoir une vue citoyenne des décisions prises par les
collectivités ou l'Etat. Ca donne aussi une vue sur l'équité de traitement
des territoires (populations réellement desservies par les services
publics, les transports, les offres commerciales, les plans d'aménagements,
les concertations publiques avec les citoyens sur les choix
d'implantation). Et c'est utile au commerce aussi.
Je ne vois pas en quoi c'est "inutile".

Le 3 janvier 2018 à 13:44, Christian Quest  a
écrit :

> Le 3 janvier 2018 à 11:51, REBOUX Maël  a
> écrit :
>
>> Bonjour,
>>
>>
>>
>> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
>> mieux ils sont malheureusement encore trop utilisés. Ils sont de taille
>> communale la plupart du temps et pas à jour ailleurs.
>>
>
>
> Ils ne sont réellement utiles que pour projeter des statistiques réalisées
> par l'INSEE avec ce maillage, pour le reste, je ne vois pas trop.
>
> Dans les quartiers où la population a changé, c'est sûr que ça ne
> représente plus grand chose de significatif, y compris les stats si elles
> n'ont pas été remises à jour par une enquête de terrain complète.
>
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Philippe Verdy]

La plupart du temps ? Non, car il y a 16100 IRIS (une paille !) définis sur
1916 communes (les plus peuplées et les plus denses)
Rien que pour Paris il y en a 992 et c'est bien plus fin que les
arrondissements, les grands quartiers ou les sous-quartiers.
Les communes non concernées sont majoritaires mais elles sont beaucoup
moins peuplées et leur découpage administratif éventuel suffit pour un
ciblage plus fin.

  Valeurs
Dep Nombre de communes Nombre d'IRIS
01 17 72
02 9 79
03 10 62
04 4 24
05 3 33
06 27 364
07 9 35
08 9 52
09 4 18
10 8 57
11 10 69
12 6 40
13 67 773
14 17 145
15 3 17
16 8 48
17 15 94
18 5 51
19 5 41
21 16 132
22 15 79
23 3 9
24 9 45
25 15 117
26 14 92
27 10 77
28 8 61
29 30 202
2A 2 28
2B 5 23
30 25 149
31 32 294
32 4 19
33 40 339
34 42 278
35 28 210
36 4 34
37 12 119
38 42 258
39 5 42
40 11 49
41 5 43
42 24 194
43 5 16
44 44 339
45 17 136
46 2 13
47 9 49
48 3 9
49 20 165
50 7 77
51 12 147
52 3 32
53 8 43
54 25 166
55 2 14
56 24 137
57 34 234
58 8 40
59 112 810
60 19 125
61 5 38
62 70 345
63 17 124
64 17 127
65 5 44
66 21 108
67 26 241
68 22 151
69 53 529
70 5 21
71 20 121
72 13 112
73 10 59
74 29 140
75 20 992
76 42 370
77 51 299
78 65 487
79 8 65
80 6 78
81 10 81
82 4 38
83 37 299
84 21 139
85 18 84
86 11 90
87 13 90
88 9 49
89 9 53
90 3 25
91 46 353
92 35 615
93 39 613
94 42 522
95 51 429
971 25 129
972 17 124
973 7 54
974 23 343
Total général 1916 16100

Le 3 janvier 2018 à 11:51, REBOUX Maël  a
écrit :

> Bonjour,
>
>
>
> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
> mieux ils sont malheureusement encore trop utilisés. Ils sont de taille
> communale la plupart du temps et pas à jour ailleurs.
>
> Nous sommes un certain nombre de « grosses » collectivités territoriales à
> avoir réclamer à l’INSEE il y a déjà qqs années maintenant une mise à jour
> de ces limites, notamment dans les zones « dynamiques » (à l’urbanisation
> qui bouge vite et donc où la population croît). L’INSEE n’a pas accédé à
> nos demandes ce qui fait que ces maillages sont obsolètes sur les zones qui
> en auraient besoin.
>
>
>
> Nous en sommes rendus à publier des mises à jour locales plus à jour des
> réalités du terrain. Exemple : https://public.sig.
> rennesmetropole.fr/geonetwork/srv/fre/catalog.search#/
> metadata/df789a3f-9980-4629-95be-50a8b04eac3c
>
>
>
> *Dans un souci de mise en adéquation des contours des différents zonages
> de gestion (quartier, périmètres électoraux...), Rennes Métropole a procédé
> à une numérisation des Iris en se basant sur des référentiels internes. Du
> fait de l'évolution des communes depuis la mise en œuvre des Iris, certains
> contours ont été revus en conséquence. De ce fait, cette couche n'est pas
> la couche officielle fournie par l'Insee (cf la description de la
> généalogie).*
>
>
>
> Cdt,
>
>
>
> *Maël REBOUX*
> Service Information Géographique Rennes Métropole
> Chargé de mission "diffusion"
>
> 02 99 86 63 71
>
> Twitter : @mael_reboux_ig 
>
>
>
> https://public.sig.rennesmetropole.fr   |  https://data.rennesmetropole.fr
>
>
>
>
>
> *De :* François Lacombe [mailto:fl.infosrese...@gmail.com]
> *Envoyé :* samedi 30 décembre 2017 17:27
> *À :* Discussions sur OSM en français
> *Objet :* *** BULK *** Re: [OSM-talk-fr] Contours des IRIS
>
>
>
> Bonjour
>
> S'agissant en plus de contours basés sur des quantités de population,
> leurs limitent varient à certains endroits j'immagine ?
>
> Les contours purement virtuels, qui n'ont pas plus d’interaction avec le
> reste des objets de la carte comme le bâti, les rivières, les
> infrastructures ont peut d'intérêt à se trouver véritablement dans OSM.
>
> On ne va pas non plus favoriser leur correction par les contributeurs en
> les plaçant sur la carte.
>
> Et je ne dis pas que ces données là n'ont pas d'intérêt, simplement qu'OSM
> ne va pas remplacer data.gouv
>
> François
>
>
>
> Le 30 décembre 2017 à 16:26, Christian Quest  a
> écrit :
>
>
>
> De plus les contours IRIS en LO sont approximatifs, ceux précis, sont
> payants...
>
>
>
> Le 29 décembre 2017 à 14:56, Cyrille37 OSM 
> a écrit :
>
> Salut
>
> Ça semble chouette d'avoir plus de données dans OSM, mais j'ai peur qu'il
> y a déjà énormément de mise à jour à suivre pour les éléments existants.
> Donc je pense que les IRIS sont très bien hors OSM et qu'il est facile pour
> qui sait faire des analyses, de les associés aux données OSM avec les
> outils adéquates.
>
> C/.
>
> Le 29/12/2017 à 13:56, Philippe Verdy a écrit :
>
> De nombreuses cartes statistiques pourraient utiliser les délimitations
> infracommunales (les IRIS).
>
> Elles sont libres (licence LO/OL).
>
> Peut-on envisager de les importer (sachant qu'on a déjà une partie de ces
> contours pour les frontières communales, et les quartiers administratifs,
> et que ces IRIS sont aussi à la base de la délimitation du fractionnement
> cantonal qui s'appuie sur les 

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[althio]

Non tu n'es pas le seul, il suffit d'aller voir la question sur :
https://github.com/gravitystorm/openstreetmap-carto/issues/2931

-- althio


2017-12-28 15:10 GMT+01:00 Vincent Frison :
> Hello,
>
> Je sais pas si je suis le seul mais pour moi les cartes affichant le relief,
> c'est à dire avec hillshade et/ou courbes de niveaux, sont bien plus jolies
> que celles sont relief. Je dirais même qu'en plus d'être plus jolies elles
> sont beaucoup plus claires car elles permettent de se repérer plus
> facilement avec le relief.
>
> Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et je
> trouve ça plus que dommage.
>
> Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le problème
> c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses fonctionnalités
> (principalement celle qui permet de chercher les objets afin de voir tous
> les détails).
>
> Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement le
> relief est assez mal rendu et puis surtout il est vraiment orienté pour les
> vélos en masquant la plupart des informations pour mettre en valeur celles
> utiles aux cyclistes.
>
> J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une option
> pour afficher le hillshade et les courbes de niveaux. c'est à dire 2 petites
> checkboxes en plus de celles existantes (permettant d'afficher les notes de
> carte, etc.).
>
> Sur le site http://opensnowmap.org en allant dans les settings on peut
> afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> l'impression que c'est juste un layer supplémentaire (avec hillshade et
> courbes de niveaux) qui s'affiche en plus de celui du rendu standard.. mais
> qui du coup n'a plus rien à voir avec le rendu classique, pour moi la valeur
> ajoutée est vraiment énorme !
>
> Suis je le seul à qui ça manque ?
>
> Et à qui devrais  je demander cette évolution ? Sur un mailing list
> particulière ou directement en créant une issue ici:
> https://github.com/gravitystorm/openstreetmap-carto ?
>
> Merci, Vincent.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] BANO / Cadastre différence nom de voie

[Christian Quest]

Sur le plan cadastral, il y a des libellés qui peuvent être différents de
ceux qu'on trouve dans FANTOIR... même si les deux sources sont la DGFiP.

Là, il n'y a que le terrain qui peut servir à départager ces incohérences.


Le 3 janvier 2018 à 13:16, Cyrille37 OSM  a
écrit :

> Salut
>
> Une différence d'orthographe pour le nom d'une rue:
> - dans BANO : Rue de H*u*ngerford
> - sur imagerie cadastre (JOSM) : Rue H*o*ngerford
> - lien osmose : http://osmose.openstreetmap.fr/fr/error/15045954115
>
> C'est étrange non ?
>
> Cyrille.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[Christian Quest]

Le 3 janvier 2018 à 11:51, REBOUX Maël  a
écrit :

> Bonjour,
>
>
>
> Les IRIS sont un pis aller en terme de maillage statistique. Faute de
> mieux ils sont malheureusement encore trop utilisés. Ils sont de taille
> communale la plupart du temps et pas à jour ailleurs.
>


Ils ne sont réellement utiles que pour projeter des statistiques réalisées
par l'INSEE avec ce maillage, pour le reste, je ne vois pas trop.

Dans les quartiers où la population a changé, c'est sûr que ça ne
représente plus grand chose de significatif, y compris les stats si elles
n'ont pas été remises à jour par une enquête de terrain complète.


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

[OSM-talk-fr] BANO / Cadastre différence nom de voie

[Cyrille37 OSM]

Salut

Une différence d'orthographe pour le nom d'une rue:
- dans BANO : Rue de H*u*ngerford
- sur imagerie cadastre (JOSM) : Rue H*o*ngerford
- lien osmose : http://osmose.openstreetmap.fr/fr/error/15045954115

C'est étrange non ?

Cyrille.

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

Re: [OSM-talk-fr] Corse et départements

[Christian Quest]

D’apres Wikipedia la CTC est équivalente à une région... mais avec un
statut un peu différent.

Le mer. 3 janv. 2018 à 10:29, Christian Quest  a
écrit :

> Encore un status bancal, comme la métropole de Lyon et le département du
> rhone...
>
> Si cette CTC chapeaute le 2A et le 2B, on peut la mettre en admin_level=5
> comme on a fait pour regrouper 69D et 69M... mais c'est quand même du
> bricolage administratif tout ça !
>
> Le 3 janvier 2018 à 10:17, Francescu GAROBY  a écrit :
>
>> Bonjour,
>> Avant de toucher aux 2 départements corses, j'aimerais qu'on me confirme
>> une chose : admin_level=6 désigne les départements, ou les conseils
>> départementaux ? Il me semblait que c'étaient les départements. De même que
>> admin_level=7 désigne les arrondissements.
>> Or, les 2 départements corses existent toujours, avec leurs préfectures
>> respectives. Ce sont les conseils départementaux qui ont disparu au
>> 01/01/2018, en fusionnant avec la CTC (l'équivalent d'un conseil régional,
>> pour faire simple).
>>
>> Bastia reste donc le chef-lieu du département de Haute-Corse, avec
>> toujours un préfet, mais plus de conseil départemental.
>>
>> Francescu
>>
>> Le 2 janvier 2018 à 23:17,  a écrit :
>>
>>> Bonjour,
>>>
>>> les départements 2A  et 2B
>>>  sont toujours en
>>> admin_level=6.
>>>
>>> N'est-ce pas plutôt :
>>> admin_level=6
>>> boundary:-2018=administrative
>>> boundary:2018-=historic
>>> boundary=historic
>>>
>>> Idem pour Bastia :
>>> admin_level=8
>>> admin_level:-2018=6
>>> admin_level:2018-=8
>>>
>>> (Ajaccio était et reste de niveau 4).
>>>
>>> Je suppose qu'un jour on reverra surgir les plaques d'immatriculation 20.
>>> Là La Poste a vu juste en conservant les codes 20xxx.
>>>
>>> Pour la Corse  (et la
>>> relation) :
>>> alt_name 
>>> =Collectivité
>>> territoriale de Corse
>>> Devient :
>>> alt_name=Collectivité de Corse
>>> alt_name:-2018=Collectivité territoriale de Corse
>>> alt_name:2018-=Collectivité de Corse
>>>
>>> Des erreurs ? Des omissions ?
>>>
>>> Jean-Yvon
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Francescu
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] *** BULK *** Re: Contours des IRIS

[REBOUX Maël]

Bonjour,

Les IRIS sont un pis aller en terme de maillage statistique. Faute de mieux ils 
sont malheureusement encore trop utilisés. Ils sont de taille communale la 
plupart du temps et pas à jour ailleurs.
Nous sommes un certain nombre de « grosses » collectivités territoriales à 
avoir réclamer à l’INSEE il y a déjà qqs années maintenant une mise à jour de 
ces limites, notamment dans les zones « dynamiques » (à l’urbanisation qui 
bouge vite et donc où la population croît). L’INSEE n’a pas accédé à nos 
demandes ce qui fait que ces maillages sont obsolètes sur les zones qui en 
auraient besoin.

Nous en sommes rendus à publier des mises à jour locales plus à jour des 
réalités du terrain. Exemple : 
https://public.sig.rennesmetropole.fr/geonetwork/srv/fre/catalog.search#/metadata/df789a3f-9980-4629-95be-50a8b04eac3c

Dans un souci de mise en adéquation des contours des différents zonages de 
gestion (quartier, périmètres électoraux...), Rennes Métropole a procédé à une 
numérisation des Iris en se basant sur des référentiels internes. Du fait de 
l'évolution des communes depuis la mise en œuvre des Iris, certains contours 
ont été revus en conséquence. De ce fait, cette couche n'est pas la couche 
officielle fournie par l'Insee (cf la description de la généalogie).

Cdt,

Maël REBOUX
Service Information Géographique Rennes Métropole
Chargé de mission "diffusion"
02 99 86 63 71
Twitter : @mael_reboux_ig

https://public.sig.rennesmetropole.fr   
|  https://data.rennesmetropole.fr


De : François Lacombe [mailto:fl.infosrese...@gmail.com]
Envoyé : samedi 30 décembre 2017 17:27
À : Discussions sur OSM en français
Objet : *** BULK *** Re: [OSM-talk-fr] Contours des IRIS

Bonjour
S'agissant en plus de contours basés sur des quantités de population, leurs 
limitent varient à certains endroits j'immagine ?
Les contours purement virtuels, qui n'ont pas plus d’interaction avec le reste 
des objets de la carte comme le bâti, les rivières, les infrastructures ont 
peut d'intérêt à se trouver véritablement dans OSM.
On ne va pas non plus favoriser leur correction par les contributeurs en les 
plaçant sur la carte.
Et je ne dis pas que ces données là n'ont pas d'intérêt, simplement qu'OSM ne 
va pas remplacer data.gouv
François

Le 30 décembre 2017 à 16:26, Christian Quest 
> a écrit :

De plus les contours IRIS en LO sont approximatifs, ceux précis, sont payants...

Le 29 décembre 2017 à 14:56, Cyrille37 OSM 
> a écrit :

Salut

Ça semble chouette d'avoir plus de données dans OSM, mais j'ai peur qu'il y a 
déjà énormément de mise à jour à suivre pour les éléments existants. Donc je 
pense que les IRIS sont très bien hors OSM et qu'il est facile pour qui sait 
faire des analyses, de les associés aux données OSM avec les outils adéquates.
C/.
Le 29/12/2017 à 13:56, Philippe Verdy a écrit :
De nombreuses cartes statistiques pourraient utiliser les délimitations 
infracommunales (les IRIS).
Elles sont libres (licence LO/OL).
Peut-on envisager de les importer (sachant qu'on a déjà une partie de ces 
contours pour les frontières communales, et les quartiers administratifs, et 
que ces IRIS sont aussi à la base de la délimitation du fractionnement cantonal 
qui s'appuie sur les statistiques fines de population calculées par IRIS).
Ce ne serait pas des frontières adminsitratives (boundary=administrative, mais 
statistiques (boundary=statistic). Et cela permettrait de recoller aussi avec 
le fractionnement cantonal des grandes communes.

On a ces données sur http://professionnels.ign.fr/contoursiris
(certes avec un tracé approximatif le long des rues, mais un tel import, ne 
concernant que les communes divisées en IRIS, pourrait dans un premier temps se 
faire sur des chemins séparés pour permettre ensuite une conflation avec les 
frontières communales ou de quartiers administratifs ou arrondissements 
municipaux).

Ces IRIS jouent un rôle important en terme de planification des projets publics 
et tout aussi important pour l'activité commerciale (zones de chalandises, 
études d'impact ou d'opportunité, etc) grace à la finesse des statistiques 
collectées par l'INSEE à ce niveau.

Peut-on créer un projet contenant une liste des communes subdivisées en IRIS 
avec un indicateur d'avancement (nombre d'IRIS à cartographier), éventuellement 
sur plusieurs sous-pages par département ou région ?

Que pensez vous du tag "boundary=statistic" (avec éventuellement un tag 
additionnel "admin_type:FR=iris" ou plutôt "border_type=FR:iris" puisque ce 
n'est pas strictement adminsitratif et qu'il n'y a pas de collectivité ou de 
personne morale associée à cette entité de découpage et d'aménagement 
territorial, très utile en France pour pouvoir représenter des tas de 
statistiques comme le propose déjà le 

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Le 3 janvier 2018 à 11:03, Vincent Frison  a
écrit :

> Bon visiblement l'absence de relief sur openstreetmap.org ne gêne pas
> grand monde mis à part moi :)
>
> Sinon je me rend compte que sur tile.openstreetmap.fr il y a une petite
> option pour afficher les hillshades d'openpistemap.org mais
> malheureusement ça ne marche pas. C'est sans doute lié au fait que le site
> openpistemap.org est lui même down ?
>

En fait j'ai l'impression que c'est l'ensemble des overlays qui déconnent
sur tile.openstreetmap.fr.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Bon visiblement l'absence de relief sur openstreetmap.org ne gêne pas grand
monde mis à part moi :)

Sinon je me rend compte que sur tile.openstreetmap.fr il y a une petite
option pour afficher les hillshades d'openpistemap.org mais malheureusement
ça ne marche pas. C'est sans doute lié au fait que le site openpistemap.org
est lui même down ?


Le 28 décembre 2017 à 15:10, Vincent Frison  a
écrit :

> Hello,
>
> Je sais pas si je suis le seul mais pour moi les cartes affichant le
> relief, c'est à dire avec hillshade et/ou courbes de niveaux, sont bien
> plus jolies que celles sont relief. Je dirais même qu'en plus d'être plus
> jolies elles sont beaucoup plus claires car elles permettent de se repérer
> plus facilement avec le relief.
>
> Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et je
> trouve ça plus que dommage.
>
> Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
> comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le
> problème c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses
> fonctionnalités (principalement celle qui permet de chercher les objets
> afin de voir tous les détails).
>
> Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement le
> relief est assez mal rendu et puis surtout il est vraiment orienté pour les
> vélos en masquant la plupart des informations pour mettre en valeur celles
> utiles aux cyclistes.
>
> J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
> relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une
> option pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
> petites checkboxes en plus de celles existantes (permettant d'afficher les
> notes de carte, etc.).
>
> Sur le site http://opensnowmap.org en allant dans les settings on peut
> afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
> l'impression que c'est juste un layer supplémentaire (avec hillshade et
> courbes de niveaux) qui s'affiche en plus de celui du rendu standard.. mais
> qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
> valeur ajoutée est vraiment énorme !
>
> Suis je le seul à qui ça manque ?
>
> Et à qui devrais  je demander cette évolution ? Sur un mailing list
> particulière ou directement en créant une issue ici: https://github.com/
> gravitystorm/openstreetmap-carto ?
>
> Merci, Vincent.
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Christian Quest]

Rendu vectoriel... et mapcat est un très bel exemple de ce qu'on peut faire
avec les données OSM + wikipédia.

Le 3 janvier 2018 à 10:40, Bruno  a écrit :

> Le 03/01/2018 à 10:25, Marc Gemis a écrit :
>
>> Connaissez-vous https://www.mapcat.com ?
>> - OSM data
>> - clic gauche
>> - des noms en langue locale et Anglais.
>>
>> m.
>>
> Je ne connaissais pas.
> Pour le changement de langue et vu le choix important, j'imagine qu'il n'y
> a pas un rendu par langage ? c'est quoi le mécanisme technique ?
>
> 2018-01-02 23:32 GMT+01:00 marc marc :
>>
>>> Bonsoir,
>>>
>>> Le 02. 01. 18 à 23:10, Cédric Frayssinet a écrit :
>>>
 Quand on passe de GMaps à OpenStreetMap.org, je trouve que l'on perd
 beaucoup à ne pas pouvoir cliquer (avec le bouton gauche)

>>> il est clair qu'un clic droit serrait beaucoup pratique et intuitif.
>>>
>>> - interroger les objets

>>> petit raccourcit : afficher l'adresse
>>> cela ne te propose souvent le bon objet.
>>>
>>> Cordialement,
>>> Marc
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Bruno]

Le 03/01/2018 à 10:25, Marc Gemis a écrit :

Connaissez-vous https://www.mapcat.com ?
- OSM data
- clic gauche
- des noms en langue locale et Anglais.

m.

Je ne connaissais pas.
Pour le changement de langue et vu le choix important, j'imagine qu'il 
n'y a pas un rendu par langage ? c'est quoi le mécanisme technique ?

2018-01-02 23:32 GMT+01:00 marc marc :

Bonsoir,

Le 02. 01. 18 à 23:10, Cédric Frayssinet a écrit :

Quand on passe de GMaps à OpenStreetMap.org, je trouve que l'on perd
beaucoup à ne pas pouvoir cliquer (avec le bouton gauche)

il est clair qu'un clic droit serrait beaucoup pratique et intuitif.


- interroger les objets

petit raccourcit : afficher l'adresse
cela ne te propose souvent le bon objet.

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

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




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

Re: [OSM-talk-fr] Corse et départements

[Christian Quest]

Encore un status bancal, comme la métropole de Lyon et le département du
rhone...

Si cette CTC chapeaute le 2A et le 2B, on peut la mettre en admin_level=5
comme on a fait pour regrouper 69D et 69M... mais c'est quand même du
bricolage administratif tout ça !

Le 3 janvier 2018 à 10:17, Francescu GAROBY  a écrit :

> Bonjour,
> Avant de toucher aux 2 départements corses, j'aimerais qu'on me confirme
> une chose : admin_level=6 désigne les départements, ou les conseils
> départementaux ? Il me semblait que c'étaient les départements. De même que
> admin_level=7 désigne les arrondissements.
> Or, les 2 départements corses existent toujours, avec leurs préfectures
> respectives. Ce sont les conseils départementaux qui ont disparu au
> 01/01/2018, en fusionnant avec la CTC (l'équivalent d'un conseil régional,
> pour faire simple).
>
> Bastia reste donc le chef-lieu du département de Haute-Corse, avec
> toujours un préfet, mais plus de conseil départemental.
>
> Francescu
>
> Le 2 janvier 2018 à 23:17,  a écrit :
>
>> Bonjour,
>>
>> les départements 2A  et 2B
>>  sont toujours en
>> admin_level=6.
>>
>> N'est-ce pas plutôt :
>> admin_level=6
>> boundary:-2018=administrative
>> boundary:2018-=historic
>> boundary=historic
>>
>> Idem pour Bastia :
>> admin_level=8
>> admin_level:-2018=6
>> admin_level:2018-=8
>>
>> (Ajaccio était et reste de niveau 4).
>>
>> Je suppose qu'un jour on reverra surgir les plaques d'immatriculation 20.
>> Là La Poste a vu juste en conservant les codes 20xxx.
>>
>> Pour la Corse  (et la
>> relation) :
>> alt_name 
>> =Collectivité
>> territoriale de Corse
>> Devient :
>> alt_name=Collectivité de Corse
>> alt_name:-2018=Collectivité territoriale de Corse
>> alt_name:2018-=Collectivité de Corse
>>
>> Des erreurs ? Des omissions ?
>>
>> Jean-Yvon
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Francescu
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Marc Gemis]

Connaissez-vous https://www.mapcat.com ?
- OSM data
- clic gauche
- des noms en langue locale et Anglais.

m.

2018-01-02 23:32 GMT+01:00 marc marc :
> Bonsoir,
>
> Le 02. 01. 18 à 23:10, Cédric Frayssinet a écrit :
>> Quand on passe de GMaps à OpenStreetMap.org, je trouve que l'on perd
>> beaucoup à ne pas pouvoir cliquer (avec le bouton gauche)
>
> il est clair qu'un clic droit serrait beaucoup pratique et intuitif.
>
>> - interroger les objets
> petit raccourcit : afficher l'adresse
> cela ne te propose souvent le bon objet.
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Bruno]

Le 03/01/2018 à 10:10, Lionel Allorge a écrit :

Bonjour,


Pour ma part j'en ai un autre qui n'est pas qu'un problème d'ergonomie :

La carte est affichée dans la langue du pays par défaut, si je regarde
la Russie ou la Pologne , et bien c'est inutilisable (pour moi)

J'ai eu le même problème et j'utilise depuis :
http://tile.openstreetmap.fr/
qui propose les noms en français lorsqu'ils existent.

Librement.

Oui je suis d'accord, c'est ce que je fais aussi et j'aurai du le dire, 
mais comme on parlait d'ergonomie et de simplicité d'emploi je trouve 
que dire aux gens tu vas sur osm.org c'est plus simple que 
"tile.openstreetmap.org".


Dommage osm.fr est déjà pris..

Bruno


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

Re: [OSM-talk-fr] Corse et départements

[Francescu GAROBY]

Bonjour,
Avant de toucher aux 2 départements corses, j'aimerais qu'on me confirme
une chose : admin_level=6 désigne les départements, ou les conseils
départementaux ? Il me semblait que c'étaient les départements. De même que
admin_level=7 désigne les arrondissements.
Or, les 2 départements corses existent toujours, avec leurs préfectures
respectives. Ce sont les conseils départementaux qui ont disparu au
01/01/2018, en fusionnant avec la CTC (l'équivalent d'un conseil régional,
pour faire simple).

Bastia reste donc le chef-lieu du département de Haute-Corse, avec toujours
un préfet, mais plus de conseil départemental.

Francescu

Le 2 janvier 2018 à 23:17,  a écrit :

> Bonjour,
>
> les départements 2A  et 2B
>  sont toujours en
> admin_level=6.
>
> N'est-ce pas plutôt :
> admin_level=6
> boundary:-2018=administrative
> boundary:2018-=historic
> boundary=historic
>
> Idem pour Bastia :
> admin_level=8
> admin_level:-2018=6
> admin_level:2018-=8
>
> (Ajaccio était et reste de niveau 4).
>
> Je suppose qu'un jour on reverra surgir les plaques d'immatriculation 20.
> Là La Poste a vu juste en conservant les codes 20xxx.
>
> Pour la Corse  (et la
> relation) :
> alt_name 
> =Collectivité
> territoriale de Corse
> Devient :
> alt_name=Collectivité de Corse
> alt_name:-2018=Collectivité territoriale de Corse
> alt_name:2018-=Collectivité de Corse
>
> Des erreurs ? Des omissions ?
>
> Jean-Yvon
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Jo]

le rendu standard de openstreetmap.org n'est pas là pour être "utilisable"
ni ergonomique, il est là pour les éditeurs pour vérifier ce qu'ils/elles
font.

Pour un rendu POI il faut d'autres solutions et OSM devrait y renvoyer.

Polyglot

2018-01-03 10:01 GMT+01:00 Stéphane Péneau :

> Le 03/01/2018 à 09:55, Bruno a écrit :
>
>>
>> La carte est affichée dans la langue du pays par défaut, si je regarde la
>> Russie ou la Pologne , et bien c'est inutilisable (pour moi)
>>
>> Osm.org devrait afficher la carte en prenant en compte la langue du
>> navigateur.
>>
>> Techniquement, et pour le moment, ça demande un rendu différent par
> langue. C'est beaucoup trop pour une petite "structure" tel que
> OpenStreetMap.
>
> Stf
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Lionel Allorge]

Bonjour,

> Pour ma part j'en ai un autre qui n'est pas qu'un problème d'ergonomie :
> 
> La carte est affichée dans la langue du pays par défaut, si je regarde
> la Russie ou la Pologne , et bien c'est inutilisable (pour moi)

J'ai eu le même problème et j'utilise depuis :
http://tile.openstreetmap.fr/
qui propose les noms en français lorsqu'ils existent.

Librement.

-- 
Lionel Allorge
April : http://www.april.org
Lune Rouge : http://www.lunerouge.org
Wikimedia France : http://wikimedia.fr
OpenStreetMap France : http://www.openstreetmap.fr/

« Bien informés, les hommes sont des citoyens;
mal informés ils deviennent des sujets. »
Alfred Sauvy

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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Stéphane Péneau]

Le 03/01/2018 à 09:55, Bruno a écrit :


La carte est affichée dans la langue du pays par défaut, si je regarde 
la Russie ou la Pologne , et bien c'est inutilisable (pour moi)


Osm.org devrait afficher la carte en prenant en compte la langue du 
navigateur.


Techniquement, et pour le moment, ça demande un rendu différent par 
langue. C'est beaucoup trop pour une petite "structure" tel que 
OpenStreetMap.


Stf

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

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[Bruno]

Le 02/01/2018 à 23:10, Cédric Frayssinet a écrit :


Bonsoir à tous,

Je vais peut-être lancer un pavé dans la mare, mais je me lance :)

Quand on passe de GMaps à OpenStreetMap.org, je trouve que l'on perd 
beaucoup à ne pas pouvoir cliquer (avec le bouton gauche) sur les 
nœuds, type commerces, restaurants ou attractions touristiques. C'est 
vraiment dommage car souvent les tags nécessaires y sont. Avec Gmaps, 
on clique puis on affiche un volet complet qui permet ce que vous savez.


Suis je le seul à trouver le menu contextuel peu pratique ?

- interroger les objets

- puis sélectionner ce que l'on souhaite dans la liste qui s'affiche 
dans le volet latéral


Je ne sais pas comment sont gérés ces travaux de développement, c'est 
pourquoi j'interroge la liste...


Bonne soirée,

Cédric


--
En cure de désintoxication  de 
Google ! Client d'Enercoop 
, l'énergie militante


Également sur Mastodon : @bristow...@framapiaf.org 



Promouvoir et soutenir le logiciel libre 



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


Bonjour,

Oui clairement il n'y a rien de très ergonomique ou même simplement 
fonctionnel pour interroger des POI sur la carte, à l'heure actuelle.


Les astuces comme passer par une recherche d'adresse ou la fonction 
requêter des objets  sont utilisables mais pas du même niveau.
Je ne sais pas non plus ou intervenir pour remonter ce genre de besoin , 
qui ne doit pas être nouveau..


Pour ma part j'en ai un autre qui n'est pas qu'un problème d'ergonomie :

La carte est affichée dans la langue du pays par défaut, si je regarde 
la Russie ou la Pologne , et bien c'est inutilisable (pour moi)


Osm.org devrait afficher la carte en prenant en compte la langue du 
navigateur.


Bruno.


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

Re: [OSM-talk-fr] Tagguer les cinémas "art & essai"

[Antoine Riche]

En anglais on parle de "arts cinema" 
(https://en.wikipedia.org/wiki/International_Confederation_of_Art_Cinemas), 
on pourrait utiliser arts=yes ou plus explicite arts_cinema=yes.


Il y a un numéro d'autorisation dans le fichier open data, on le met en 
ref:FR:CNC ?


De nombreuses salles Arts et Essai en Europe sont membres du réseau 
Europa Cinemas (http://www.europa-cinemas.org/), tant qu'à y être on 
pourrait les identifier avec brand=Europa Cinemas


Ce qui donne (pour les zélés) :
arts_cinema=yes (toute salle se réclamant Arts et Essai, avec ou sans 
label selon les pays)

ref:FR:CNC=
cinema:FR:art_essai=A|B|C|D|E  (salles classés par le CNC)
brand=Europa Cinemas (pour les salles du réseau)

La valeur no pour cinema:FR:art_essai ne me semble plus utile si on 
applique les autres tags, on aurait plutôt arts_cinema=no


Antoine.

Le 02/01/2018 à 23:24, marc marc a écrit :

Le 02. 01. 18 à 22:57, osm.sanspourr...@spamgourmet.com a écrit :

Le 02/01/2018 à 21:10, George Kaplan - georgekaplan...@hotmail.fr a écrit :

De façon similaire à school:FR, ça donne plutôt cinema:FR=art_essai .
Est-ce qu’il y a un terme du CNC pour les cinémas qui ne sont pas
« art et essai » ?


Oui, c'est dans la liste citée et ça s'appelle "NON";-).
Je propose simplement :
cinema:FR:art_essai=A|B|C|D|E|no

étant donné que chaque cinéma est susceptible de diffuser ce genre de
film, ne serrait-il pas intéressant d'essayer de trouver un nom de tag
anglais "parent" qui puisse s'appliquer "mondialement" sous la forme
cinema: =yes/no ?

avoir un tag commun permet un jour d'avoir un outil qui permet de
trouver un tel cinéma peu importe s'il se trouve à Roubais ou à Mons.

cela n’empêche pas d'avoir un tag :FR pour l'affinage de la
classification niveau français mais qui irait dans un sous-tag du tag
avec le mot anglais comme c'est la tradition dans osm.
par analogie, on utilise school:FR et non pas ecole:FR
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ergonomie d'OpenStreetMap.org

[David Crochet]

Bonjour


Le 03/01/2018 à 08:57, David Crochet a écrit :

sur la gauche pour cela


Droite, je voulais dire droite.

Cordialement

--
David Crochet


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