Re: [OSM-talk-fr] serveurs TMS/XYZ

[Christian Quest]

Depuis qu'on a mis en place un cache en front du serveur de tuiles, on
encaisse beaucoup mieux la charge et surtout les pics.

Tout dépend du niveau de zoom nécessaire, pour les zooms 0 à 11, les
mbtiles sont téléchargeables pour réutilisation locale.

Don contre autorisation, c'est une forme de prestation dans laquelle on ne
souhaite pas rentrer en tant qu'association à but non lucratif. C'est sûr
que plus l'asso a de moyens financiers, plus c'est facile de fournir un
service stable, mais on le garantira jamais en "retour" d'un don.

Déployer un serveur de tuile s'est quand même pas mal simplifié ces
derniers temps, il y a désormais quelques stack proposées relativement
faciles à déployer. Une fois correctement installé, un serveur de tuile est
quelque chose de très stable. osm13 tourne sans vrai besoin d'intervention.

Déployer une stack sur un serveur dédié ça doit prendre disons 2 jours...
et ensuite ça coûte moins d'une centaine d'euros par mois en location aux
tarifs actuels OVH ou online.net


Le 17 mars 2016 à 05:51,  a écrit :

> Bonjour,
> d'abord la partie OSM "pure" : MapQuest confirme qu'ils vont interdire
> l'accès direct à leur serveur de tuiles.
> Ils ont encore une offre gratuite limitée en transactions par mois mais
> leur politique de copyright devient gaguesque :
> http://ibin.co/2aU3xFtcSt5j
> (non ce n'est pas une blague, ça se passe ici
> , la première option
> raisonnable dans mon cas - je parle du nombre de logos sur la page - c'est
> au-delà de la version business+ à 800 $/mois).
>
> Donc fini les tuiles MapQuest en fond de carte tuilée.
> Au fait, leur API n'est pas mal pour faire des cartes statiques simples.
>
> J'ai regardé ce qui existait d'autre (je cherche des serveurs de tuiles
> TMS/XYZ/WMS/... pour de la cartographie ou/et des l'imagerie en descendant
> au niveau de la rue).
>
> MapBox, c'est à partir de 500 $/mois pour une application payante ou une
> application privée ou une application de suivi. Oui c'est bien un ou (info
> confirmée par eux).
> GeoFabrik, c'est à partir de 35 € par mois.
>
> A priori en usage gratuit et libre (sous réserve de tampon sur la page),
> je trouve Stamen et CartoDB.
> Aucun n'affiche les pontons (man_made=pier : ils vident les ports ;-)).
> ViaMichelin non plus.
> Vous connaissez des alternatives ?
>
> Pour l'imagerie photo, de bonne qualité il y a MapBox. Le prix va avec...
> MapQuest : avec la politique de logos... quoique si en cliquant on ouvre
> une photo avec logo, ça va. Mais en dehors des États-Unis, c'est médiocre.
> Here/VisualEarth (utilisé par ViaMichelin) : je n'ai pas trouvé les infos
> précises pour le moment, si vous avez ça sous la main...
>
> N. B. : c'est pour un produit avec peu d'utilisateurs - 2 postes dans un
> cas précis et peu d'installations. Mais sur le monde (enfin une bonne
> partie d'un sous-continent). Donc un service dans les nuages est adapté.
> Déployer un serveur pour ça, ça fait beaucoup.
> Ça peut aussi être un don à OSM France contre autorisation d'utiliser les
> tuiles du site.
>
> Jean-Yvon
>
> ___
> 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] Fwd: relations boundary admin_level=4 manquantes

[Philippe Verdy]

Note: les noms des atolls ou des iles/motus ne sont pas ceux non plus des
localités/villages, même si ce sont parfois des noms de communes.

Improprement on dit "archipel des Gambiers", quand c'est en fait un seul et
même atoll (encore en formation mais la couronne est déjà totalement
formée), avec une couronne coralienne supportant quelques motus (mais pas
les "iles" qui sont actuellement représentées et qui sont trop morcelées),
et des iles hautes au centre du lagon, dont 5 sont habitées.

C'est le seul atoll de ce type dans les Tuamotus, les autres sont habités
sur les motus car il n'y a plus d'ile haute centrale (normal, cet atoll
s'est formé par un volcan plus récent pas encore complètement effondré au
centre)

Parmi les autres atolls seuls quelques-uns n'ont plus de lagon (ce sont des
"atolls surélevés", dont l'élévation vient soit d'un plissement du plancher
océanique sous le poids d'autres massifs volcaniques proches, soit de la
reformation d'un point chaud en dessous, soit de l'abaissement du niveau de
la mer ; leur ancien lagon s'est vidé de son eau par la croissance
coralienne puis comblé complètement par l'apport de sables par le vent ou
l'érosion de la couronne surélevée vers le centre): on peut qualifier ces
lagons "d'îles" et non plus de "motus" puisqu'on ne distingue plus leur
couronne coralienne

Sinon le travail n'est pas terminé évidemment, car je ne me suis pas
attaqué à dessiner les couronnes récifales liant les "motus" (et ne laisser
en mer que les véritables "passes" quand elles existent)

Je ne sais pas d'où viennent les tracés des "îles" actuelles, elles sont
toutes là (je n'y ai pas touché), mais franchement le niveau de précision
est très mauvais et il y a des iles séparées qui ne devraient pas l'être du
tout. On dirait que cela vient d'une analyse sur des photos basse
résolution où on s'est contenté de chercher les endroits où il y a de la
verdure (des cocotiers essentiellement). Mais sur la couronnne il y a bien
des endroits qui sont en fait émergés en permanence (donc pas d'eau dessus,
sauf évènement exceptionnel tel qu'une submersion par un cyclone, mais qui
pourrait aussi toucher la plupart des motus tracés hors des rares "iles
hautes"). Ces tracés comportent beaucoup trop de passes très larges et
laissent des atolls complètement ouverts, ce qui ne correspond pas du tout
à la réalité.



Le 20 mars 2016 à 03:49, Philippe Verdy  a écrit :

> Note: avant il n'y avait strictement aucune commune, juste les limites
> territoriales maritimes.
> Les iles n'étaient dans aucune collectivité précise. Il faut bien
> commencer quelque part
>
> Le 20 mars 2016 à 03:48, Philippe Verdy  a écrit :
>
>> je veux bien mais ces frontières n'étaient pas tracées (ce qui est travé
>> comme contour des îles ce sont des motus très peu précis, pas le contour
>> des atolls avec leur couronne récifale)
>> Pour l'instant je m'appuie sur ce qui est là, en attendant d'ajouter les
>> couronne récifales qui sont incluses dans la ligne de base.
>>
>>
>> Le 20 mars 2016 à 03:24, Jérôme Amagat  a écrit
>> :
>>
>>> En France métropolitaine les communes s'arrêtent à la ligne
>>> natural=coastline qui est censé être une laisse de haute mer. les laisses
>>> de basse mer et les lignes de base ne serve qu'à tracer les limites à 24
>>> miles pour les frontières des pays.
>>> Pourquoi Philippe tu veux faire différemment là, pour les admin_level=8,
>>> il faut utiliser les frontières terre mer déjà tracés.
>>>
>>> (si je suis a coté des problème de chacun, je veux dire que j'ai pas
>>> tout bien comprit, que j'ai regardé rapidement et que je sais pas comment
>>> c’était avant :) ).
>>>
>>> Le 19 mars 2016 à 23:27, Philippe Verdy  a écrit :
>>>
 Bref cet utilisateur allemand (tout seul en fait: "wambacher") se
 trompe sur toute la ligne, il a mal regardé ou fait de fausses suppositions
 sur le découpage français.

 Le 19 mars 2016 à 23:23, Philippe Verdy  a écrit :

> Sinon méfiance avec ce que disent les allemands qui croient à tord
> qu'on a viré des codes postaux en France, alors que les communes 
> fusionnées
> qui n'ont pas de code postal sont celles dont les communes membres ont des
> codes postaux différents (et qui les gardent). En France les codes postaux
> ne sont pas découpés exactement comme les communes. Même dans les communes
> simples (sans fusion) on a plusieurs zones postales (grandes villes
> uniquement), et cela ne devrait pas les surprendre en Allemagne vu qu'ils
> ont aussi des communes découpées par les zones postales.
>
> De même certains n'étaient pas au courant des fusions de régions alors
> que tout est OK (ils n'ont pas regardé les start_date/end_date ou les ont
> mal analysés). (D'où les prétentues régions manquantes en admin_level 4)
>
> Ils ne sont pas au courant non plus de a scission du département du

Re: [OSM-talk-fr] Fwd: relations boundary admin_level=4 manquantes

[Philippe Verdy]

Note: avant il n'y avait strictement aucune commune, juste les limites
territoriales maritimes.
Les iles n'étaient dans aucune collectivité précise. Il faut bien commencer
quelque part

Le 20 mars 2016 à 03:48, Philippe Verdy  a écrit :

> je veux bien mais ces frontières n'étaient pas tracées (ce qui est travé
> comme contour des îles ce sont des motus très peu précis, pas le contour
> des atolls avec leur couronne récifale)
> Pour l'instant je m'appuie sur ce qui est là, en attendant d'ajouter les
> couronne récifales qui sont incluses dans la ligne de base.
>
>
> Le 20 mars 2016 à 03:24, Jérôme Amagat  a écrit :
>
>> En France métropolitaine les communes s'arrêtent à la ligne
>> natural=coastline qui est censé être une laisse de haute mer. les laisses
>> de basse mer et les lignes de base ne serve qu'à tracer les limites à 24
>> miles pour les frontières des pays.
>> Pourquoi Philippe tu veux faire différemment là, pour les admin_level=8,
>> il faut utiliser les frontières terre mer déjà tracés.
>>
>> (si je suis a coté des problème de chacun, je veux dire que j'ai pas tout
>> bien comprit, que j'ai regardé rapidement et que je sais pas comment
>> c’était avant :) ).
>>
>> Le 19 mars 2016 à 23:27, Philippe Verdy  a écrit :
>>
>>> Bref cet utilisateur allemand (tout seul en fait: "wambacher") se trompe
>>> sur toute la ligne, il a mal regardé ou fait de fausses suppositions sur le
>>> découpage français.
>>>
>>> Le 19 mars 2016 à 23:23, Philippe Verdy  a écrit :
>>>
 Sinon méfiance avec ce que disent les allemands qui croient à tord
 qu'on a viré des codes postaux en France, alors que les communes fusionnées
 qui n'ont pas de code postal sont celles dont les communes membres ont des
 codes postaux différents (et qui les gardent). En France les codes postaux
 ne sont pas découpés exactement comme les communes. Même dans les communes
 simples (sans fusion) on a plusieurs zones postales (grandes villes
 uniquement), et cela ne devrait pas les surprendre en Allemagne vu qu'ils
 ont aussi des communes découpées par les zones postales.

 De même certains n'étaient pas au courant des fusions de régions alors
 que tout est OK (ils n'ont pas regardé les start_date/end_date ou les ont
 mal analysés). (D'où les prétentues régions manquantes en admin_level 4)

 Ils ne sont pas au courant non plus de a scission du département du
 Rhône en deux parties et confondent l'ancien département (devenu
 circonscription départementale et regroupant le nouveau département avec la
 métropole) et le nouveau, qui sont tagués différemment 
 (start_date/end_date)



 Le 19 mars 2016 à 23:14, Philippe Verdy  a écrit :

> Tu parles des îles Tuamotus ? Je n'ai rien viré du tout, tout est là,
> il manque encore des éléments pour quelques atolls mais ils n'étaient pas
> encore là et je les ajoute.
> Le gros changement est la séparation des entités physiques (motus et
> ilots), leur regroupement par commune ou par commune associée, l'ajout des
> noms manquants, et l'inclusion des délimitations administratives (quoique
> encore basée sur une limitation maritime territoriale), car pour l'instant
> il manque la prise en compte des lignes de base (qui de toute façon quand
> elles étaient là, n'était pas du tout utilisées, donc je n'ai rien viré)
>
>
> Le 19 mars 2016 à 15:29, althio  a écrit :
>
>> Toujours sur le même forum international, dans le même sujet, par le
>> même contributeur.
>>
>> Cette fois sa question porte sur les addr:postcode et homogénéité des
>> données en France, avec quelques zones qui ne suivent pas le schéma.
>>
>> Si cela intéresse quelqu'un de se pencher les données ou de lui
>> répondre ?
>> http://forum.openstreetmap.org/viewtopic.php?pid=576687#p576687
>>
>> - althio
>>
>>
>>
>>
>> -- Forwarded message --
>> Date: 6 January 2016 at 14:52
>> Subject: relations boundary admin_level=4 manquantes
>> To: Discussions sur OSM en français 
>>
>>
>> Pour info, un message passé sur le forum international :
>> http://forum.openstreetmap.org/viewtopic.php?id=53229
>>
>> [quote]
>> Hi, there are a lot of boundaries with admin_level=4 missing in
>> france:
>>
>> I see only 7 of them. Any idea, whats going on there?
>>
>> Regards
>> walter/germany
>> [/quote]
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>

>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> 

Re: [OSM-talk-fr] Fwd: relations boundary admin_level=4 manquantes

[Philippe Verdy]

je veux bien mais ces frontières n'étaient pas tracées (ce qui est travé
comme contour des îles ce sont des motus très peu précis, pas le contour
des atolls avec leur couronne récifale)
Pour l'instant je m'appuie sur ce qui est là, en attendant d'ajouter les
couronne récifales qui sont incluses dans la ligne de base.


Le 20 mars 2016 à 03:24, Jérôme Amagat  a écrit :

> En France métropolitaine les communes s'arrêtent à la ligne
> natural=coastline qui est censé être une laisse de haute mer. les laisses
> de basse mer et les lignes de base ne serve qu'à tracer les limites à 24
> miles pour les frontières des pays.
> Pourquoi Philippe tu veux faire différemment là, pour les admin_level=8,
> il faut utiliser les frontières terre mer déjà tracés.
>
> (si je suis a coté des problème de chacun, je veux dire que j'ai pas tout
> bien comprit, que j'ai regardé rapidement et que je sais pas comment
> c’était avant :) ).
>
> Le 19 mars 2016 à 23:27, Philippe Verdy  a écrit :
>
>> Bref cet utilisateur allemand (tout seul en fait: "wambacher") se trompe
>> sur toute la ligne, il a mal regardé ou fait de fausses suppositions sur le
>> découpage français.
>>
>> Le 19 mars 2016 à 23:23, Philippe Verdy  a écrit :
>>
>>> Sinon méfiance avec ce que disent les allemands qui croient à tord qu'on
>>> a viré des codes postaux en France, alors que les communes fusionnées qui
>>> n'ont pas de code postal sont celles dont les communes membres ont des
>>> codes postaux différents (et qui les gardent). En France les codes postaux
>>> ne sont pas découpés exactement comme les communes. Même dans les communes
>>> simples (sans fusion) on a plusieurs zones postales (grandes villes
>>> uniquement), et cela ne devrait pas les surprendre en Allemagne vu qu'ils
>>> ont aussi des communes découpées par les zones postales.
>>>
>>> De même certains n'étaient pas au courant des fusions de régions alors
>>> que tout est OK (ils n'ont pas regardé les start_date/end_date ou les ont
>>> mal analysés). (D'où les prétentues régions manquantes en admin_level 4)
>>>
>>> Ils ne sont pas au courant non plus de a scission du département du
>>> Rhône en deux parties et confondent l'ancien département (devenu
>>> circonscription départementale et regroupant le nouveau département avec la
>>> métropole) et le nouveau, qui sont tagués différemment (start_date/end_date)
>>>
>>>
>>>
>>> Le 19 mars 2016 à 23:14, Philippe Verdy  a écrit :
>>>
 Tu parles des îles Tuamotus ? Je n'ai rien viré du tout, tout est là,
 il manque encore des éléments pour quelques atolls mais ils n'étaient pas
 encore là et je les ajoute.
 Le gros changement est la séparation des entités physiques (motus et
 ilots), leur regroupement par commune ou par commune associée, l'ajout des
 noms manquants, et l'inclusion des délimitations administratives (quoique
 encore basée sur une limitation maritime territoriale), car pour l'instant
 il manque la prise en compte des lignes de base (qui de toute façon quand
 elles étaient là, n'était pas du tout utilisées, donc je n'ai rien viré)


 Le 19 mars 2016 à 15:29, althio  a écrit :

> Toujours sur le même forum international, dans le même sujet, par le
> même contributeur.
>
> Cette fois sa question porte sur les addr:postcode et homogénéité des
> données en France, avec quelques zones qui ne suivent pas le schéma.
>
> Si cela intéresse quelqu'un de se pencher les données ou de lui
> répondre ?
> http://forum.openstreetmap.org/viewtopic.php?pid=576687#p576687
>
> - althio
>
>
>
>
> -- Forwarded message --
> Date: 6 January 2016 at 14:52
> Subject: relations boundary admin_level=4 manquantes
> To: Discussions sur OSM en français 
>
>
> Pour info, un message passé sur le forum international :
> http://forum.openstreetmap.org/viewtopic.php?id=53229
>
> [quote]
> Hi, there are a lot of boundaries with admin_level=4 missing in france:
>
> I see only 7 of them. Any idea, whats going on there?
>
> Regards
> walter/germany
> [/quote]
>
> ___
> 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] Fwd: relations boundary admin_level=4 manquantes

[Jérôme Amagat]

En France métropolitaine les communes s'arrêtent à la ligne
natural=coastline qui est censé être une laisse de haute mer. les laisses
de basse mer et les lignes de base ne serve qu'à tracer les limites à 24
miles pour les frontières des pays.
Pourquoi Philippe tu veux faire différemment là, pour les admin_level=8, il
faut utiliser les frontières terre mer déjà tracés.

(si je suis a coté des problème de chacun, je veux dire que j'ai pas tout
bien comprit, que j'ai regardé rapidement et que je sais pas comment
c’était avant :) ).

Le 19 mars 2016 à 23:27, Philippe Verdy  a écrit :

> Bref cet utilisateur allemand (tout seul en fait: "wambacher") se trompe
> sur toute la ligne, il a mal regardé ou fait de fausses suppositions sur le
> découpage français.
>
> Le 19 mars 2016 à 23:23, Philippe Verdy  a écrit :
>
>> Sinon méfiance avec ce que disent les allemands qui croient à tord qu'on
>> a viré des codes postaux en France, alors que les communes fusionnées qui
>> n'ont pas de code postal sont celles dont les communes membres ont des
>> codes postaux différents (et qui les gardent). En France les codes postaux
>> ne sont pas découpés exactement comme les communes. Même dans les communes
>> simples (sans fusion) on a plusieurs zones postales (grandes villes
>> uniquement), et cela ne devrait pas les surprendre en Allemagne vu qu'ils
>> ont aussi des communes découpées par les zones postales.
>>
>> De même certains n'étaient pas au courant des fusions de régions alors
>> que tout est OK (ils n'ont pas regardé les start_date/end_date ou les ont
>> mal analysés). (D'où les prétentues régions manquantes en admin_level 4)
>>
>> Ils ne sont pas au courant non plus de a scission du département du Rhône
>> en deux parties et confondent l'ancien département (devenu circonscription
>> départementale et regroupant le nouveau département avec la métropole) et
>> le nouveau, qui sont tagués différemment (start_date/end_date)
>>
>>
>>
>> Le 19 mars 2016 à 23:14, Philippe Verdy  a écrit :
>>
>>> Tu parles des îles Tuamotus ? Je n'ai rien viré du tout, tout est là, il
>>> manque encore des éléments pour quelques atolls mais ils n'étaient pas
>>> encore là et je les ajoute.
>>> Le gros changement est la séparation des entités physiques (motus et
>>> ilots), leur regroupement par commune ou par commune associée, l'ajout des
>>> noms manquants, et l'inclusion des délimitations administratives (quoique
>>> encore basée sur une limitation maritime territoriale), car pour l'instant
>>> il manque la prise en compte des lignes de base (qui de toute façon quand
>>> elles étaient là, n'était pas du tout utilisées, donc je n'ai rien viré)
>>>
>>>
>>> Le 19 mars 2016 à 15:29, althio  a écrit :
>>>
 Toujours sur le même forum international, dans le même sujet, par le
 même contributeur.

 Cette fois sa question porte sur les addr:postcode et homogénéité des
 données en France, avec quelques zones qui ne suivent pas le schéma.

 Si cela intéresse quelqu'un de se pencher les données ou de lui
 répondre ?
 http://forum.openstreetmap.org/viewtopic.php?pid=576687#p576687

 - althio




 -- Forwarded message --
 Date: 6 January 2016 at 14:52
 Subject: relations boundary admin_level=4 manquantes
 To: Discussions sur OSM en français 


 Pour info, un message passé sur le forum international :
 http://forum.openstreetmap.org/viewtopic.php?id=53229

 [quote]
 Hi, there are a lot of boundaries with admin_level=4 missing in france:

 I see only 7 of them. Any idea, whats going on there?

 Regards
 walter/germany
 [/quote]

 ___
 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] Fwd: relations boundary admin_level=4 manquantes (osm: message 3 of 20)

[Philippe Verdy]

Cet utilisateur ("wambach") se plaint du fait que j'aurais viré les
découpages communaux des Tuamotus, ce qui est entièrement faux. Il n'y en
avait pas du tout puisqu'il n'y avait que les frontières des eaux
territoriales de la France

Sinon les îles sont très grossièrement dessinées (un vieil import) et ce
qui est représenté est en fait les "motus", pas les atolls entiers (sur
lesquels sont définis les "baselines")

Il manque les récifs coralliens qui les lient entre eux les motus et qui
sont découverts à marée basse. Sinon il manque aussi les lignes de base
(quand elles y sont, elles n'étaient pas encore utilisées comme limites
communales).

Je suis en train de faire le tri dans tout ça. Il y a d'autres éléments à
ajouter (des *noeuds* "place=island" notamment dont certains seront en fait
des noms d'atolls entiers et non des nom de motus; mais cela n'a pas
d'influence sur le découpage des zones terrestres (ce que j'ai regroupé,
atoll par atoll dans des "land_area" mais qui ne servent pas du tout aux
limites adminsitratives, ce que prétend à tord "wambach")

Au passage il y a une amélioration de la précision par endroit mais c'est à
faire dans un second temps, car il faudra de toute façon ajouter les récifs
de l'anneau coralien et localiser les véritables "passes" dans les atolls
(il y en a trop si on se base sur le tracé actuel approximatifs des "iles",
en fait des motus), pour fermer les atolls correctement, et ensuite avoir
de vraies lignes de base.


Le 19 mars 2016 à 23:33,  a écrit :

> > Sinon méfiance avec ce que disent les allemands qui croient à tord qu'on
> a viré des codes postaux en
> Non ils disent que pour éviter ce genre de problème ils ont décidé en
> Allemagne de dissocier les découpages administratif des découpages postaux.
> Dans 90 % des cas c'est identique et dans 10 % des cas c'est différent.
> On doit être un peu dans les mêmes métriques.
>
> Le 2016-03-19 23:23, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
>
> ___
> 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] Fwd: relations boundary admin_level=4 manquantes (osm: message 3 of 20)

[osm . sanspourriel]

> Sinon méfiance avec ce que disent les allemands qui croient à tord 
qu'on a viré des codes postaux en
Non ils disent que pour éviter ce genre de problème ils ont décidé en 
Allemagne de dissocier les découpages administratif des découpages postaux.

Dans 90 % des cas c'est identique et dans 10 % des cas c'est différent.
On doit être un peu dans les mêmes métriques.

Le 2016-03-19 23:23, Philippe Verdy - verd...@wanadoo.fr a écrit :

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

Re: [OSM-talk-fr] Fwd: relations boundary admin_level=4 manquantes

[Philippe Verdy]

Bref cet utilisateur allemand (tout seul en fait: "wambacher") se trompe
sur toute la ligne, il a mal regardé ou fait de fausses suppositions sur le
découpage français.

Le 19 mars 2016 à 23:23, Philippe Verdy  a écrit :

> Sinon méfiance avec ce que disent les allemands qui croient à tord qu'on a
> viré des codes postaux en France, alors que les communes fusionnées qui
> n'ont pas de code postal sont celles dont les communes membres ont des
> codes postaux différents (et qui les gardent). En France les codes postaux
> ne sont pas découpés exactement comme les communes. Même dans les communes
> simples (sans fusion) on a plusieurs zones postales (grandes villes
> uniquement), et cela ne devrait pas les surprendre en Allemagne vu qu'ils
> ont aussi des communes découpées par les zones postales.
>
> De même certains n'étaient pas au courant des fusions de régions alors que
> tout est OK (ils n'ont pas regardé les start_date/end_date ou les ont mal
> analysés). (D'où les prétentues régions manquantes en admin_level 4)
>
> Ils ne sont pas au courant non plus de a scission du département du Rhône
> en deux parties et confondent l'ancien département (devenu circonscription
> départementale et regroupant le nouveau département avec la métropole) et
> le nouveau, qui sont tagués différemment (start_date/end_date)
>
>
>
> Le 19 mars 2016 à 23:14, Philippe Verdy  a écrit :
>
>> Tu parles des îles Tuamotus ? Je n'ai rien viré du tout, tout est là, il
>> manque encore des éléments pour quelques atolls mais ils n'étaient pas
>> encore là et je les ajoute.
>> Le gros changement est la séparation des entités physiques (motus et
>> ilots), leur regroupement par commune ou par commune associée, l'ajout des
>> noms manquants, et l'inclusion des délimitations administratives (quoique
>> encore basée sur une limitation maritime territoriale), car pour l'instant
>> il manque la prise en compte des lignes de base (qui de toute façon quand
>> elles étaient là, n'était pas du tout utilisées, donc je n'ai rien viré)
>>
>>
>> Le 19 mars 2016 à 15:29, althio  a écrit :
>>
>>> Toujours sur le même forum international, dans le même sujet, par le
>>> même contributeur.
>>>
>>> Cette fois sa question porte sur les addr:postcode et homogénéité des
>>> données en France, avec quelques zones qui ne suivent pas le schéma.
>>>
>>> Si cela intéresse quelqu'un de se pencher les données ou de lui répondre
>>> ?
>>> http://forum.openstreetmap.org/viewtopic.php?pid=576687#p576687
>>>
>>> - althio
>>>
>>>
>>>
>>>
>>> -- Forwarded message --
>>> Date: 6 January 2016 at 14:52
>>> Subject: relations boundary admin_level=4 manquantes
>>> To: Discussions sur OSM en français 
>>>
>>>
>>> Pour info, un message passé sur le forum international :
>>> http://forum.openstreetmap.org/viewtopic.php?id=53229
>>>
>>> [quote]
>>> Hi, there are a lot of boundaries with admin_level=4 missing in france:
>>>
>>> I see only 7 of them. Any idea, whats going on there?
>>>
>>> Regards
>>> walter/germany
>>> [/quote]
>>>
>>> ___
>>> 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] Fwd: relations boundary admin_level=4 manquantes

[Philippe Verdy]

Sinon méfiance avec ce que disent les allemands qui croient à tord qu'on a
viré des codes postaux en France, alors que les communes fusionnées qui
n'ont pas de code postal sont celles dont les communes membres ont des
codes postaux différents (et qui les gardent). En France les codes postaux
ne sont pas découpés exactement comme les communes. Même dans les communes
simples (sans fusion) on a plusieurs zones postales (grandes villes
uniquement), et cela ne devrait pas les surprendre en Allemagne vu qu'ils
ont aussi des communes découpées par les zones postales.

De même certains n'étaient pas au courant des fusions de régions alors que
tout est OK (ils n'ont pas regardé les start_date/end_date ou les ont mal
analysés). (D'où les prétentues régions manquantes en admin_level 4)

Ils ne sont pas au courant non plus de a scission du département du Rhône
en deux parties et confondent l'ancien département (devenu circonscription
départementale et regroupant le nouveau département avec la métropole) et
le nouveau, qui sont tagués différemment (start_date/end_date)



Le 19 mars 2016 à 23:14, Philippe Verdy  a écrit :

> Tu parles des îles Tuamotus ? Je n'ai rien viré du tout, tout est là, il
> manque encore des éléments pour quelques atolls mais ils n'étaient pas
> encore là et je les ajoute.
> Le gros changement est la séparation des entités physiques (motus et
> ilots), leur regroupement par commune ou par commune associée, l'ajout des
> noms manquants, et l'inclusion des délimitations administratives (quoique
> encore basée sur une limitation maritime territoriale), car pour l'instant
> il manque la prise en compte des lignes de base (qui de toute façon quand
> elles étaient là, n'était pas du tout utilisées, donc je n'ai rien viré)
>
>
> Le 19 mars 2016 à 15:29, althio  a écrit :
>
>> Toujours sur le même forum international, dans le même sujet, par le
>> même contributeur.
>>
>> Cette fois sa question porte sur les addr:postcode et homogénéité des
>> données en France, avec quelques zones qui ne suivent pas le schéma.
>>
>> Si cela intéresse quelqu'un de se pencher les données ou de lui répondre ?
>> http://forum.openstreetmap.org/viewtopic.php?pid=576687#p576687
>>
>> - althio
>>
>>
>>
>>
>> -- Forwarded message --
>> Date: 6 January 2016 at 14:52
>> Subject: relations boundary admin_level=4 manquantes
>> To: Discussions sur OSM en français 
>>
>>
>> Pour info, un message passé sur le forum international :
>> http://forum.openstreetmap.org/viewtopic.php?id=53229
>>
>> [quote]
>> Hi, there are a lot of boundaries with admin_level=4 missing in france:
>>
>> I see only 7 of them. Any idea, whats going on there?
>>
>> Regards
>> walter/germany
>> [/quote]
>>
>> ___
>> 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] serveurs TMS/XYZ

[osm . sanspourriel]

Je confirme, ça marche mais ce n'était pas ma question ;-).

J'avais d'ailleurs fait une installation sur ProMox comme conseillé par Christian.

Je n'avais pris qu'une petite partie d'OSM et pas installé la partie mise-à-jour.

 

Christian, c'est simplement qu'on a un usage limité (par défaut carte non activée et quelques utilisateurs par installation, pas beacoup d'installations) donc l'idée c'était plus un service en ligne.

 

Oui j'ai bien vu les MTiles que vous mettez à disposition :
http://osm13.openstreetmap.fr/~cquest/tms/

Ca veut dire que pour les niveaux 12 et plus il faut recourir à un "vrai" serveur.


Car là je dois descendre au niveau de la rue et ce pour une zone assez large (plusieurs pays). Donc des besoins d'un serveur mondial avec une charge faible.

 

Dans le temps il y avait tiles@home qui était séduisant, chacun contribuant mais visiblement il y avait un noeud central consommateur de bande passante. Si nous avions la possibilité de mutualiser de petites machines, ça pourrait le faire, non ?

 

C'est vrai que le temps que je passe à chercher des serveurs j'aurais mieux fait de le passer à installer un serveur !

Mais suivant de quel côté de l'Atlantique je me trouve, la maintenance d'un servuer 24/7 fait peur ou pas. Et pas du côté que vous pensez !

 

De plus on a un cache sur les postes clients, donc une interruption de service est gênante, pas bloquante.

 


Jean-Yvon

 
 

>> Déployer un serveur de tuile s'est quand même pas mal simplifié ces
>> derniers temps, il y a désormais quelques stack proposées relativement
>> faciles à déployer. Une fois correctement installé, un serveur de
>> tuile est quelque chose de très stable.

> Elle est où la doc pour ça ?

https://switch2osm.org/fr/servir-des-tuiles/





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

[OSM-talk-fr] Recherche de bénévoles pour activités OSM humanitaires : Post-validation sur HOT + import de données dans OSM

[Martin Noblecourt]

Bonjour à tous,

J'imagine qu'une majorité des contributeurs sur cette liste connaît déjà 
CartONG, l'association française de la cartographie humanitaire. 
http://cartong.org/fr


Nous sommes non seulement des grands "consommateurs" de donnée OSM, mais 
nous essayons également de promouvoir OSM, aussi bien auprès des 
organisations humanitaires avec lesquelles nous travaillons (pour les 
pousser à utiliser OSM mais aussi à ouvrir leurs données), ainsi qu'en 
encourageant la contribution en France (vous avez du voir passer des 
invitations aux mapathons que nous organisons maintenant régulièrement) 
et à l'international.
Pour aller plus loin, nous avons identifié des activités plus avancées 
pour lesquelles nous sommes à la recherche de contributeurs OSM 
expérimentés, pour guider nos bénévoles et salariés dans la définition 
de bonnes pratiques et flux de travail, et pour nous aider à 
l'implémentation.
Les deux premières activités consistent à publier dans OSM la donnée 
produite sur le terrain par les techniciens SIG que nous envoyons sur le 
terrain avec notre partenaire Médecins Sans Frontières (afin que cette 
donnée soit utile à tous : noms de lieux, emplacements de services 
clés...), et à "finaliser" les projets que nous organisons sur le 
tasking manager de HOT (en mettant au propre la donnée OSM sur la zone 
par une vérification globale).


Nous cherchons idéalement des personnes se trouvant en région 
Rhône-Alpes (notamment pour la première activité) car il y aura besoin 
d'une phase de travail en équipe dans nos locaux à Chambéry au 
démarrage. Cependant si vous êtes particulièrement intéressés et vous 
trouvez plus loin nous essaierons de trouver un format qui convienne à 
tous ;-)


N'hésitez pas à me contacter si vous avez des questions !

Bien à vous,

--
Martin Noblecourt

*m_nobleco...@cartong.org | Bureau/Office: +33 (0)4 79 26 28 82 | Skype: 
martin.noblecourt*
CartONG - Mapping and information management for humanitarian 
organizations | Cartographie et gestion de l'information pour les 
organisations humanitaires
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] serveurs TMS/XYZ

[Christian Quest]

Le 17 mars 2016 à 19:12, Jean-Claude Repetto  a écrit :

> MapProxy


Un bête cache HTTP suffit... nginx dans mon cas c'est d'ailleurs ce qui est
utilisé en front sur osm13 avec apache/mod_tile/renderd derrière.
Rien d'autre à installer, quelques lignes de config et hop, ça roule.


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

[OSM-talk-fr] Fwd: relations boundary admin_level=4 manquantes

[althio]

Toujours sur le même forum international, dans le même sujet, par le
même contributeur.

Cette fois sa question porte sur les addr:postcode et homogénéité des
données en France, avec quelques zones qui ne suivent pas le schéma.

Si cela intéresse quelqu'un de se pencher les données ou de lui répondre ?
http://forum.openstreetmap.org/viewtopic.php?pid=576687#p576687

- althio




-- Forwarded message --
Date: 6 January 2016 at 14:52
Subject: relations boundary admin_level=4 manquantes
To: Discussions sur OSM en français 


Pour info, un message passé sur le forum international :
http://forum.openstreetmap.org/viewtopic.php?id=53229

[quote]
Hi, there are a lot of boundaries with admin_level=4 missing in france:

I see only 7 of them. Any idea, whats going on there?

Regards
walter/germany
[/quote]

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

[OSM-talk-fr] "type=*" déprécié dans les relations?

[Philippe Verdy]

J'ai vu à plusieurs endroits que le tag type=* serait déprécié dans les
relations, parce qu'il est en fait ambigu, et parce que les relations
peuvent en fait simultanément de plusieurs types différents.

Cela concernait la plupart des valeurs données à type=* dont
- type=boundary : remplacé par le tag plus approprié "boundary=*"
- type=land_area : remplacé par le tag plus approprié "boundary=land_area"
voire même seulement "land-area=*"
- type=route : remplacé (?) par le tag plus spécifique route=*
- type=natural (quelques occurences) : remplacé par le tag natural=*
- type=multipolygon : pas signifiant du tout, historique, mais encore
généré par défaut dans les éditeurs, à priori inutile. Si le but est de
bien indiquer que cela concerne la surface et non le seul contour, c'est le
cas par défaut dans toutes les relations (sauf les "route=*" pour les
itinéraires), sinon on a "area=yes/no" pour changer cette valeur par défaut

Note:
- "area=yes" n'est à priori pas utile pour les relations puisque c'est la
valeur par défaut de toutes les relations, sauf route=* (et "route=*" n'a
pas de sens en tant que surface, à moins que ce soit pour mentionner qu'un
itinéraire passe par une zone où n'existe aucun sens de circulation ni
aucun chemin spécifique) ; en revanche il reste utile pour les relations
avec "highway=*" qui peuvent avoir besoin de mentionner une surface
(exemple les zones piétonnes avec "highway=pedestrian"), et dans ce cas
cette relation surfacique highway=* pourrait être un des membres d'un
itinéraire piéton (route=*).
- "area=no" n'est semble-t-il pas utile (c'est déjà la valeur par défaut
pour les "highway=*" et pour les "route=*")

Que se passe-t-il si on n'a QUE type=* et aucune des tags de remplacement
(comme ceux-dessus : pour les utiliser il faut cependant leur donner une
valeur et ce n'est pas si évident, en tout cas pas automatiquement.

Tout au plus :
- pour une relation "type=highway", le tag de remplacement "highway=*"
pourrait utiliser une valeur "highway=unspecified" (et donc supprimer
automatiquement "type=highway")
- pour une relation "type=boundary", le tag de remplacement "boundary=*"
n'a pas de valeur par défaut (même si la plupart du temps c'est
"boundary=administrative", cela reste à vérifier.
- pour une relation "type=route", le tag de remplacement "route=*" n'a pas
de valeur par défaut non plus (même si souvent c'est "route=bus", il y a
d'autres modes de transport possibles)

A-t-on une analyse permettant de trouver les relations utilisant
"type=" mais aucun tag "=*" ? Ces relations devraient être
précisées (car en attendant on ne peut pas supprimer "type=XYZ".

Est-il prévu une réelle obsolescence du tag "type=*" (y compris
"type=multipolygon" qui ne sert à rien du tout) pour les relations ?

Votre avis sur la question : faut-il encore mettre "type=*" dans les
relations, au moins le temps d'assurer la migration des tags plus
spécifiques manquants (même si cela fait doublon quand ce tag plus
spécifique est déjà présent) ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] "type=*" déprécié dans les relations?

[Jo]

Je suis beaucoup de listes en plusieurs langues et ceci est le premier
message que j'ai vu qui parle de décommissioner type= pour les relations.

Polyglot

2016-03-17 22:55 GMT+01:00 JB :

> Un lien, s'il te plait ?
> Ou même deux ou trois, comme tu dis que tu en as vu plein ?
> JB.
>
> Le 17/03/2016 20:30, Philippe Verdy a écrit :
>
>> Justement je commence à en voir un peu partout dans le wiki documentaire.
>>
>
>
> ___
> 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] Mapotempo recrute 2 développeurs : web & Android / C++

[Frédéric Rodrigo]

Bonjour,

Un message pour vous signaler que Mapotempo recrute à Bordeaux :
- un développeur full stack web (ruby, mais connaissance non prérequise) 
: optimisation d'itinéraires de livraison basé sur OSM et OSRM
- un développeur Android / C++ : évolution application mobile de 
navigation off-line



https://cadres.apec.fr/home/mes-offres/recherche-des-offres-demploi/liste-des-offres-demploi/detail-de-loffre-demploi.html?numIdOffre=161428766W

https://cadres.apec.fr/home/mes-offres/recherche-des-offres-demploi/liste-des-offres-demploi/detail-de-loffre-demploi.html?numIdOffre=161428760W


http://mapotempo.com


Frédéric.


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

Re: [OSM-talk-fr] serveurs TMS/XYZ

[osm . sanspourriel]

Et avec deux utilisateurs qui vont regarder a priori les mêmes zones, le proxy standard aura fait le boulot.
 

Jean-Yvon

 
 

Gesendet: Donnerstag, 17. März 2016 um 19:17 Uhr
Von: "Christian Quest - cqu...@openstreetmap.fr" 
An: "Discussions sur OSM en français" 
Betreff: Re: [OSM-talk-fr] serveurs TMS/XYZ



 
Le 17 mars 2016 à 19:12, Jean-Claude Repetto  a écrit :

MapProxy



Un bête cache HTTP suffit... nginx dans mon cas c'est d'ailleurs ce qui est utilisé en front sur osm13 avec apache/mod_tile/renderd derrière.

Rien d'autre à installer, quelques lignes de config et hop, ça roule.



--

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] serveurs TMS/XYZ

[Arnaud Vandecasteele]

Hello,

Sur un sujet similaire si vous connaissez un serveur de tuiles XYZ je suis
preneur.

Merci d'avance.

Arnaud

2016-03-17 8:51 GMT+04:00 :

> Bonjour,
> d'abord la partie OSM "pure" : MapQuest confirme qu'ils vont interdire
> l'accès direct à leur serveur de tuiles.
> Ils ont encore une offre gratuite limitée en transactions par mois mais
> leur politique de copyright devient gaguesque :
> http://ibin.co/2aU3xFtcSt5j
> (non ce n'est pas une blague, ça se passe ici
> , la première option
> raisonnable dans mon cas - je parle du nombre de logos sur la page - c'est
> au-delà de la version business+ à 800 $/mois).
>
> Donc fini les tuiles MapQuest en fond de carte tuilée.
> Au fait, leur API n'est pas mal pour faire des cartes statiques simples.
>
> J'ai regardé ce qui existait d'autre (je cherche des serveurs de tuiles
> TMS/XYZ/WMS/... pour de la cartographie ou/et des l'imagerie en descendant
> au niveau de la rue).
>
> MapBox, c'est à partir de 500 $/mois pour une application payante ou une
> application privée ou une application de suivi. Oui c'est bien un ou (info
> confirmée par eux).
> GeoFabrik, c'est à partir de 35 € par mois.
>
> A priori en usage gratuit et libre (sous réserve de tampon sur la page),
> je trouve Stamen et CartoDB.
> Aucun n'affiche les pontons (man_made=pier : ils vident les ports ;-)).
> ViaMichelin non plus.
> Vous connaissez des alternatives ?
>
> Pour l'imagerie photo, de bonne qualité il y a MapBox. Le prix va avec...
> MapQuest : avec la politique de logos... quoique si en cliquant on ouvre
> une photo avec logo, ça va. Mais en dehors des États-Unis, c'est médiocre.
> Here/VisualEarth (utilisé par ViaMichelin) : je n'ai pas trouvé les infos
> précises pour le moment, si vous avez ça sous la main...
>
> N. B. : c'est pour un produit avec peu d'utilisateurs - 2 postes dans un
> cas précis et peu d'installations. Mais sur le monde (enfin une bonne
> partie d'un sous-continent). Donc un service dans les nuages est adapté.
> Déployer un serveur pour ça, ça fait beaucoup.
> Ça peut aussi être un don à OSM France contre autorisation d'utiliser les
> tuiles du site.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

Arnaud Vandecasteele
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://geotribu.net/
http://about.me/arnaud_vandecasteele
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] "type=*" déprécié dans les relations?

[Vincent de Château-Thierry]

Bonjour,

> De: "Philippe Verdy" 
> 
> J'ai vu à plusieurs endroits que le tag type=* serait déprécié dans
> les relations, parce qu'il est en fait ambigu, et parce que les
> relations peuvent en fait simultanément de plusieurs types
> différents.

Philippe, tu as un lien vers les endroits en question ? Autant je trouve le tag 
type=* complètement inutile (et ses déclinaisons en espace de nom "*:type=*"), 
autant le déprécier a des conséquences sur pas mal d'implémentations où un 
filtre se fait sur la valeur du tag type=*. Ce serait un changement majeur, qui 
mérite une diffusion large (et du temps). Merci pour tes infos supplémentaires.

vincent

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

Re: [OSM-talk-fr] serveurs TMS/XYZ

[Ludovic Hirlimann]

On 17/03/2016 15:18, Christian Quest wrote:
>
> Déployer un serveur de tuile s'est quand même pas mal simplifié ces
> derniers temps, il y a désormais quelques stack proposées relativement
> faciles à déployer. Une fois correctement installé, un serveur de
> tuile est quelque chose de très stable. osm13 tourne sans vrai besoin
> d'intervention.
Elle est où la doc pour ça ?

Ludo

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

[OSM-talk-fr] Suppression de landuses

[Adrian]

Un contributeur a supprimé plusieurs polygones 'landuse'. La plupart, mais pas 
tous, sont des données Corine (CLC).

Voir, par exemple
https://www.openstreetmap.org/changeset/37751550

https://www.openstreetmap.org/changeset/37727275
https://www.openstreetmap.org/changeset/37727114
Ici il a supprimé un des quatre 'inner' et le 'outer' d'un multipolygone.

https://www.openstreetmap.org/changeset/37726551
Ici il a supprimé deux polygones, dont un était le 'outer' d'un multipolygone 
avec six 'inner'. La relation multipolygone est tagguée landuse=vineyard. En 
conséquence, des zones bâties des communes de Florensac, Pomérols et Pinet (34) 
sont devenues des vignobles dans le rendu principal de la carte 
(openstreetmap.org).

https://www.openstreetmap.org/changeset/37712462

https://www.openstreetmap.org/changeset/37700255
Ici suppression 7 jours après la création.

Il y en a peut-être d'autres. Je n'ai pas cherché plus loin dans le passé. Au 
premier coup d'oeil, les autres changements faits par ce contributeur 
paraissent raisonnables. Il a même ajouté des tags sur une relation 
multipolygone (1600920) mais peut-être avec iD on ne voit pas si on taggue une 
relation ou un chemin. Je ne m'y connais pas vraiment quand il s'agit des 
landuses. Je souhaite vos avis sur ce que le contributeur a fait.

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

Re: [OSM-talk-fr] "type=*" déprécié dans les relations?

[Philippe Verdy]

Justement je commence à en voir un peu partout dans le wiki documentaire.
Ce qui laisse penser que cela a été discuté quelquepart (sur une liste de
discussion anglophone ou ailleurs).
Mais avant de les nettoyer, il serait bon de faire le tour des applis qui
peuvent en dépendre, et voir comment les convertir correctement.
Ceci dit, je n'ai rien contre la dépréciation du "type=*" dans les
relations (y compris "type=multipolygon" qui ne sert strictement à rien)

Le 17 mars 2016 à 16:32, Vincent de Château-Thierry  a
écrit :

> Bonjour,
>
> > De: "Philippe Verdy" 
> >
> > J'ai vu à plusieurs endroits que le tag type=* serait déprécié dans
> > les relations, parce qu'il est en fait ambigu, et parce que les
> > relations peuvent en fait simultanément de plusieurs types
> > différents.
>
> Philippe, tu as un lien vers les endroits en question ? Autant je trouve
> le tag type=* complètement inutile (et ses déclinaisons en espace de nom
> "*:type=*"), autant le déprécier a des conséquences sur pas mal
> d'implémentations où un filtre se fait sur la valeur du tag type=*. Ce
> serait un changement majeur, qui mérite une diffusion large (et du temps).
> Merci pour tes infos supplémentaires.
>
> 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