Re: [OSM-talk-fr] boundary et addr:postcode / postal_code

[Philippe Verdy]

Oui à condition de tenir compte des exceptions : les zones postales ne
suivent pas exactement les limites administratives !
On doit pouvoir indiquer un **autre** code postal sur des petits objets qui
sont totalement dans une zone plus grande où l'indication n'est qu'une
valeur par défaut. Enfin il existe des objets qui sont à cheval sur deux
zones administratives (dont de grands bâtiments industriels, agricoles, ou
commerciaux) et il faut bien pouvoir y mentionner un code postal applicable
quand il y en a deux en concurrence et qu'un seul s'applique réellement.
De même si un petit objet n'utilise pas le code postal géographique mais un
code postal spécial (type CEDEX). Il se trouve qu'à proprement parler les
codes postaux ne sont pas réellement partie de l'adresse, mais du système
de distribution postal. L'adresse elle-même consiste en l'indication
précise de la commune (ce peut être une commune déléguée), du nom ou numéro
de voie, et d'un numéro sur cette voie ou d'un nom de lieu-dir le long de
cette voie si elle n'est pas numérotée. Certaines voies n'ayant également
pas de nom, on peut y trouver à la place une mention comme "voie communale
n° 6" ou "CR 7" dans le champ "addr:street". Les codes postaux c'est autre
chose et ne définissent pas réellement l'adresse, c'est propre à
l'organisation de la poste qui ne suit pas le découpage admisnitratif des
communes (ou des quartiers dans le cas des communes découpées en plusieurs
zones postales).

En Belgique et Allemagne c'est résolu de façon élégante avec des
"boundary=postal_code", où le code postal y est indiqué par
"postal_code=n", et il n'est alors fait mention nulle par de
"addr:postcode" (sauf pour les codes de distribution spéciale comparables à
nos CEDEX): il y a une plus claire distinction entre l'adresse légale et
administrative (bien plus précise) et  l'adresse postale (souvent très
floue et de plus en plus floue avec les réformes en cours de la Poste qui
tend à scinder son service de distribution en fonction de classes de
service définies chacune sur des zones de plus en plus grandes, mais qui en
revanche se recouvrent entre elles selon la classe de service : cela
devrait s'accentuer avec la concurrence car les autres distributeurs
postaux ne sont pas satisfaits du vieux découpage de la poste).

L'ARCEP aurait du s'en occuper afin de redéfinir un découpage et homogène
du territoire indépendant des distributeurs postaux, et nettement mieux
adapté aux zones de distribution postales voulues aujourd'hui par les
différents distributeurs pour l'organisation de leurs services (Elle
pourrait s'inspirer du modèle britannique).

D'autres pays ont choisi de mettre en place un code postal géographique
basé sur une grille régulière de coordonnées (avec des codes hiérarchisés
qu'on peut allonger pour plus de précision dans les zones denses, et
indépendants aussi des découpages administratifs ou légaux, ce qui ne les
empêche pas non plus de compléter ce code géographique d'un code de classe
de service lui-même étendu du nécessaire d'un code supplémentaire propre à
chaque opérateur/distributeur s'ils ont des classes de service différentes).

L'idée serait de reprendre un plan de numérotation postal national
comparable à celui de la téléphonie, avec des tranches de numéros pour
chaque opérateur après un préfixe géographique relativement lâche limité
par département (voire par "grande région" comme les 5 zones téléphoniques
françaises), chaque opérateur se chargeant ensuite de faire son découpage
en classes de service et en zone pour utiliser les numéros du bloc qui leur
est assigné. Mais alors nos vieux codes postaux à 5 chiffres pourraient
devenir plus longs (6 ou 7 chiffres) et pourraient aussi inclure des
lettres (comme les codes britanniques), tout en gardant un format fixe
facilitant le traitement (pas comme au Royaume-Uni) ni même aux USA (leur
"zipcode" comprend deux types de codes, un code court générique et un autre
allongé ajoutant plus de précision).

En France, dans les documents légaux d'ailleurs (notamment notariés, mais
aussi des rapports d'enquête judiciaire ou des enquêtes publiques) ce n'est
pas le code postal qui sert à indiquer clairement un lieu, mais bien le
découpage administratif des communes (référencées par leur code INSEE
géographique, conservé même en cas de fusion de communes) puis le découpage
cadastral des communes, car le code postal, le nom des rues, et la
numérotation ou les toponymes de lieux-dits ou noms de bâtiments ne sont
pas assez stables avec le temps. Les communes actuelles en tant que
collectivités locales ne sont pas identifiées légalement par leur code
postal, ni même par leur code INSEE géographique, mais par le code SIREN...



Le lun. 15 oct. 2018 à 23:50, marc marc  a
écrit :

> Le 15. 10. 18 à 23:11, Ralf Treinen a écrit :
> > On Mon, Oct 15, 2018 at 08:08:18PM +, marc marc wrote:
> >> Le 15. 10. 18 à 21:48, Ralf Treinen a écrit :
> >>
> >>> Le wiki semble indiquer que c'est postal_code [1].
> >>
> >> oui. 

Re: [OSM-talk-fr] Problème îlot et doublon relation ?

[Philippe Verdy]

La solution de mettre un landuse=* (ou un natural=*) est correcte: il y a
assez de valeurs même pour des indications approximatives. Cela marche pour
les plages, les zones rocheuses, les zones visiblement agricoles, les
forêts, les zones habitées (bien qu'un doute puisse exister sur le fait
qu'elles soient en fait commerciales/industrielles mais en général
residential est relativement facile à déterminer avec peu d'erreur et admet
qu'il puissse exister aussi des industries isolées dedans, ou des zones
d'écoles).

De toute façon ça ne PEUT PAS être pire que ce qu'il y avait avant qui
taguait la zone recouverte comme une surface de mer ! C'est déjà une
amélioration immédiate, et on n'a pas besoin d'attendre des semaines pour
que ce soit pris en compte.

Et rien n'empêche (en cas de doute sur la valeur de natural=* ou landuse=*
ou water=* utilisée) d'ajouter un FIXME=* (c'est une façon encore plus
propre d'éviter d'oublier cette incertitude).


Le lun. 15 oct. 2018 à 19:46, Jérôme Amagat  a
écrit :

>
>
> Le lun. 15 oct. 2018 à 13:29, Waxy  a écrit :
>
>> Salut,
>>
>> J'ai modifié un îlot, pour l'enceindre d'un lagon et il n'est plus rendu
>> sur les cartes.
>> Même si on n'étiquette pas pour le rendu je soupçonne un problème parce
>> que j'ai étiqueté de la même manière que d'autres îlots qui sont bien
>> rendus ! J'ai dû merder à un moment mais je sais pas quand 
>>
>> - L'îlot de Pamandzi mal rendu est au sein de la relation 8 801 671
>> - Exemple d'îlots correctement rendus : îles Choazil, relation 8 789 735
>>
>> Je pense qu'il n'y a pas de problème. Par contre la partie bleu de
> l’océan qui est obtenu grâce au tag natural=coastline est très longue à se
> mettre à jour. Je ne sais pas du tout comment ça marche mais j'ai déjà eu
> le même problème et je pense que ce bleu se mettra a jour d'ici 1 ou 2
> semaines. (une autre solution c'est de mettre une autre couleur par dessus
> en ajoutant un landuse=*, mais on tag pas pour le rendu donc il faut
> choisir le bon landuse :) )
>
>
>> Par ailleurs n'y a-t-il pas doublon entre les relations 1 363 069 et 3
>> 388 394 ?
>>
>> Une des relations c'est pour le département de Mayotte et l'autre pour la
> région. il y a la même chose dans les 2 relations vu que Mayotte est à la
> fois un département et une région mais il y a des tags différents,
> admin_level=4 et admin_level=6 surtout.
>
>
>> @+
>>
>> ___
>> 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] openinframap

[marc marc]

tu le connais mieux que moi mais j'espère qu'il n'est pas contre
un PR et qu'il a au moins le temps de regarder/merger les PR.
sinon il y a le fork :) au moins pour faciliter la "vue"
des contributeurs sur le sujet

Le 15. 10. 18 à 23:44, François Lacombe a écrit :
> Je confirme.
> 
> Il faut voir sur le github, il y a quelques issues en suspend.
> Ca devrait être traité d'ici la fin de l'année, mais Russ n'a pas 
> toujours le temps
> 
> Si seulement on pouvait être plusieurs à l'admin :)
> 
> *François Lacombe*
> 
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com 
> @InfosReseaux 
> 
> 
> Le lun. 15 oct. 2018 à 22:53, Vincent Privat  > a écrit :
> 
> Du coup je sais pas si c'est judicieux le label "Substation 20kv"
> pour tous les postes sans nom. La carte au zoom 13 est saturée
> maintenant :D
> 
> Le lun. 15 oct. 2018 à 21:27, Laurent Combe  > a écrit :
> 
> cool
> 
> Le ven. 12 oct. 2018 à 13:39, François Lacombe
> mailto:fl.infosrese...@gmail.com>> a
> écrit :
> 
> Bonjour
> 
> Le serveur de tuiles d'OpenInfraMap est de nouveau opérationnel.
> Les mises a jour ont été faites.
> 
> François
> 
> Le sam. 1 sept. 2018 à 12:23, François Lacombe
>  > a écrit :
> 
> Bonjour
> 
> A noter que russs n'intervient sur openinframap qu'entre
> Noel et le nouvel an habituellement
> 
> J'ai bien proposé de l'aider dans sa tache mais sans
> réponse. Il y a pourtant beaucoup à faire
> 
> Bonne journée
> 
> François
> 
> Le sam. 1 sept. 2018 à 10:26, marc marc
>  > a écrit :
> 
> Bonjour,
> 
> info de Gazer75 (qui ne parle pas français) sur irc :
> I think it has stopped due to a problem,
> but ru is quite busy atm.
> 
> en français : il y a un problème :-)
> mais "russs", le gars qui s'en occupe, est débordé
> pour le moment.
> Le mieux est de prendre contact directement avec lui
> ou chercher s'ils
> ont un système de ticket pour être au courant des
> changements.
> 
> Cordialement,
> Marc
> 
> Le 01. 09. 18 à 08:44, Laurent Combe a écrit :
>  > petit up gentil
>  > le problème de rafraichissement semble toujours
> présent
>  >
>  > Le mer. 22 août 2018 à 21:34, François Lacombe
>  >  
>  >> a écrit :
>  >
>  >     Bonsoir,
>  >
>  >     Relativement à ce problème, il semble
> toujours présent dans la zone
>  >
> https://openinframap.org/#13/43.8486/1.4224/Power-Telecoms
>  >
>  >     Il y a comme une espèce de ligne au nord de
> laquelle rien ne passe.
>  >     Surement un problème de mise à jour
>  >     A voir si les admins consentent à recharger
> la base
>  >
>  >     François
>  >
>  >     Le lun. 20 août 2018 à 08:48, François Lacombe
>  >      
>  >> a écrit :
>  >
>  >         Bonjour Laurent
>  >
>  >         En effet, on dirait qu'il y a une ligne
> horizontale au nord de
>  >         laquelle il n'y a pas de postes ou de lignes
>  >
>  >         On va attendre encore quelques jours pour
> voir si ca se débloque
>  >
>  >         François
>  >
>  >         Le lun. 20 août 2018 à 08:13, Laurent Combe
>  >          
>  

Re: [OSM-talk-fr] boundary et addr:postcode / postal_code

[marc marc]

Le 15. 10. 18 à 23:11, Ralf Treinen a écrit :
> On Mon, Oct 15, 2018 at 08:08:18PM +, marc marc wrote:
>> Le 15. 10. 18 à 21:48, Ralf Treinen a écrit :
>>
>>> Le wiki semble indiquer que c'est postal_code [1].
>>
>> oui. postal_code pour définir le code postal d'une étendue
>> par opposition à addr:postcode pour définir le code postal
>> d'une addr en particulier.
> 
> Merci pour cette confirmation. Et on est bien d'accord que quand
> le postal_code est renseigné pour une étendu avec admin_level=9
> (les arrondissements de Paris) qu'il n'est pas utile de le
> repeter sur les quartiers (adminlevel=10) inclus dans cet arrondissement ?

pour moi c'est (tjs?) inutile de répéter 2 fois la même chose :)
donc si c'est sur admin_level=9, pas besoin de le remettre sur les 
niveau 10 ni sur tous objet inférieur (genre les bâtiments)
ils vont tous hériter de l'info du niveau supérieur (comme on le fait 
pour les communes par ex).
on gagnerait bcp en lisibilité pour trouver les endroits oü il manque 
l'info... parce que pour l'instant il faut d'abord se farcir une logique 
éliminatoire/corrective pour prétraiter les données :(
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] openinframap

[François Lacombe]

Je confirme.

Il faut voir sur le github, il y a quelques issues en suspend.
Ca devrait être traité d'ici la fin de l'année, mais Russ n'a pas toujours
le temps

Si seulement on pouvait être plusieurs à l'admin :)

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 


Le lun. 15 oct. 2018 à 22:53, Vincent Privat  a
écrit :

> Du coup je sais pas si c'est judicieux le label "Substation 20kv" pour
> tous les postes sans nom. La carte au zoom 13 est saturée maintenant :D
>
> Le lun. 15 oct. 2018 à 21:27, Laurent Combe  a
> écrit :
>
>> cool
>>
>> Le ven. 12 oct. 2018 à 13:39, François Lacombe 
>> a écrit :
>>
>>> Bonjour
>>>
>>> Le serveur de tuiles d'OpenInfraMap est de nouveau opérationnel.
>>> Les mises a jour ont été faites.
>>>
>>> François
>>>
>>> Le sam. 1 sept. 2018 à 12:23, François Lacombe <
>>> fl.infosrese...@gmail.com> a écrit :
>>>
 Bonjour

 A noter que russs n'intervient sur openinframap qu'entre Noel et le
 nouvel an habituellement

 J'ai bien proposé de l'aider dans sa tache mais sans réponse. Il y a
 pourtant beaucoup à faire

 Bonne journée

 François

 Le sam. 1 sept. 2018 à 10:26, marc marc  a
 écrit :

> Bonjour,
>
> info de Gazer75 (qui ne parle pas français) sur irc :
> I think it has stopped due to a problem,
> but ru is quite busy atm.
>
> en français : il y a un problème :-)
> mais "russs", le gars qui s'en occupe, est débordé pour le moment.
> Le mieux est de prendre contact directement avec lui ou chercher s'ils
> ont un système de ticket pour être au courant des changements.
>
> Cordialement,
> Marc
>
> Le 01. 09. 18 à 08:44, Laurent Combe a écrit :
> > petit up gentil
> > le problème de rafraichissement semble toujours présent
> >
> > Le mer. 22 août 2018 à 21:34, François Lacombe
> > mailto:fl.infosrese...@gmail.com>> a
> écrit :
> >
> > Bonsoir,
> >
> > Relativement à ce problème, il semble toujours présent dans la
> zone
> > https://openinframap.org/#13/43.8486/1.4224/Power-Telecoms
> >
> > Il y a comme une espèce de ligne au nord de laquelle rien ne
> passe.
> > Surement un problème de mise à jour
> > A voir si les admins consentent à recharger la base
> >
> > François
> >
> > Le lun. 20 août 2018 à 08:48, François Lacombe
> > mailto:fl.infosrese...@gmail.com>>
> a écrit :
> >
> > Bonjour Laurent
> >
> > En effet, on dirait qu'il y a une ligne horizontale au nord
> de
> > laquelle il n'y a pas de postes ou de lignes
> >
> > On va attendre encore quelques jours pour voir si ca se
> débloque
> >
> > François
> >
> > Le lun. 20 août 2018 à 08:13, Laurent Combe
> > mailto:laurent.co...@free.fr>> a
> écrit :
> >
> > alors quelque chose m'échappe
> > au nord de toulouse, commune de Fronton par exemple , la
> > carte affichée par openinframap ne se réactualise plus
> > depuis qques jours
> > aucune nouvelle ligne electrique n'apparait dans ce
> secteur
> >
> > j'ai viré cookie, cache, ...
> >
> > je ne vois pas
> >
> > Laurent
> >
> >
> > Le dim. 19 août 2018 à 19:54, François Lacombe
> >  > > a écrit :
> >
> > Bonjour
> >
> > Environ 1 cache de 24h
> >
> > François
> >
> > Le dim. 19 août 2018 à 19:38, Laurent Combe
> > mailto:laurent.co...@free.fr>>
> a
> > écrit :
> >
> > Bonjour
> >
> > Savez-vous a quelle fréquence se regénère les
> tuiles
> > d'OpenInfraMap ?
> >
> > Laurent
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > 
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org  Talk-fr@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org  Talk-fr@openstreetmap.org>

Re: [OSM-talk-fr] boundary et addr:postcode / postal_code

[Philippe Verdy]

J'ai eu des messages demandant de faire l'inverse : ne plus utiliser
postal_code et utiliser addr:postcode, justement parce que addr:postcode
est énormément plus utilisé en France. On m'a demandé de remettre
addr:postcode, même sur les relations d'étendue alors que justement j'avais
voulu suivre la recommendation du wiki et d'Osmose.

Visiblement tout le monde ne semble pas d'accord, et en fait l'une ou
l'autre information sont traitées finalement comme équivalentes.

Tant qu'on veut utiliser les deux, il y aura toujours des confusions car
souvent les attributs d'une relation et d'un noeud admin_centre sont
changés en même temps.

Certes les relations communales ne sont pas des "adresses" à proprement
parler, mais même si on met addr:postcode dans ces relations cela ne
devrait pas gêner du tout et cela ne fournit qu'une valeur par défaut
appliquée sur les noeuds d'adresse situés dedans, ceux-ci pouvant tout à
fait modifier cette valeur par défaut, mais n'étant alors plus obligés non
plus d'indiquer le code postal indiqué dans la plus petite relation
administrative qui ne contient.

Il ne semble donc y avoir eu aucun consensus sur ce sujet dans OSM en
général et pas plus seulement en France. Ce serait bien de se mettre
d'accord afin d'éviter les va-et-viens entre les avis des uns et ceux des
autres (j'en ai vu avoir des points de vues très tranchés et finalement
assez menaçants au point de vouloir invoquer le DWG. Mais comme il n'y a
aucun consebsus pour l'instant, ce serait bien de faire taire les
polémiques menaçantes de certains sur ce sujet.

C'est bien à nous de décider au moins en France ici (et ne pas penser que
le wiki impose tout pour la France alors qu'il est aussi fait pour d'autres
pays et utilisateurs francophones, et que les autres pays ont plutôt un
consensus local inversé). Si c'est mentionné dans le wiki, même sur la page
en français ou dans d'autres langues, il vaut mieux y indiquer que le
consensus est documenté pays par pays et que pour cela on a dans le wiki
des pages spéciales concernant les conventions propres à chaque pays (les
pages "Tagging guidelines") qui peuvent trancher sur des questions non
résolues sur les pages documentant chaque tag de façon plus générique (et
ceci indépendamment des langues où c'est traduit).

On ne peut pas faire de décision actuellement sur les pages Wiki des tags
sans passer par un consensus mondial applicable pour tous les pays et
toutes les langues et dans ce cas il faut juste y mentionner que les
conventions sont plutôt dans les pages "Tagging guidelines" par pays en se
contenant de recenser les Tags alternatifs proposés. Si un rendu ou toute
autre réutilisation ne sait pas interprêter les conventions pays par pays,
les pages de tags doivent leur demander de traiter par défaut ces tags
comme équivalents.

Cependant il faut éviter les contradictions : on ne devrait en aucun cas
avoir sur le même objet les deux tags addr:postcode et postal_code, sinon
les rendus et rutilisations n'ont aucun moyen de déterminer laquelle des
deux valeurs utiliser (il m'est arrivé de tomber sur des objets mentionnant
des codes postaux différents entre les deux tags présents simultanément sur
le même objet, et dans ce cas les rendus et réutilisation auront un
comportement imprévisible et un tel cas devrait être celui réellement
signalé par Osmose comme une réelle erreur; sinon je pense qu'il ne faut
pas tenir compte de l'indication donnée par Osmose demandant de remplacer
l'un par l'autre).


Le lun. 15 oct. 2018 à 23:12, Ralf Treinen  a écrit :

> On Mon, Oct 15, 2018 at 08:08:18PM +, marc marc wrote:
> > Le 15. 10. 18 à 21:48, Ralf Treinen a écrit :
> >
> > > Le wiki semble indiquer que c'est postal_code [1].
> >
> > oui. postal_code pour définir le code postal d'une étendue
> > par opposition à addr:postcode pour définir le code postal
> > d'une addr en particulier.
>
> Merci pour cette confirmation. Et on est bien d'accord que quand
> le postal_code est renseigné pour une étendu avec admin_level=9
> (les arrondissements de Paris) qu'il n'est pas utile de le
> repeter sur les quartiers (adminlevel=10) inclus dans cet arrondissement ?
>
> -Ralf.
>
> ___
> 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] Afficher sa position GPS sur une carte uMap

[Yann Schneylin]

Bonjour à tous et merci pour vos réponses. 

Effectivement, en modifiant l'URL de la carte uMap en https plutôt qu'en
http, le bouton cible fonctionne (même si je ne comprends pas pourquoi
!). 

Ce bouton permet donc de centrer la carte sur sa localisation GPS, mais
pas d'afficher le point précis de sa localisation. Or c'est la fonction
dont j'aurais besoin, pour les objectifs suivants : 

Exemple 1 : 

https://umap.openstreetmap.fr/fr/map/carte-des-capitelles_39012#16/43.8352/4.1718


Je souhaite retrouver sur le terrain un point d'intérêt issu d'un
inventaire participatif. 

Exemple 2 : 

https://umap.openstreetmap.fr/fr/map/parcours-de-mons-la-trivalle_116027#16/43.5708/2.9685


Je souhaite vérifier ma position sur un sentier découverte. 

Ces 2 cartes sont publiques et destinées à mettre en valeur auprès du
grand public le patrimoine bâti et naturel d'un territoire.

Yann SCHNEYLIN
Les Écologistes de l'Euzière
Domaine de Restinclières
34730 PRADES-LE-LEZ
Standard : 04 67 59 54 62
Portable : 07 50 21 70 34
www.euziere.org [1] 

Le 15.10.2018 19:18, Philippe Verdy a écrit :

> Note: une telle extension posera des problèmes légaux en Europe vis-à-vis du 
> RGPD : en effet si elle colelcte en continu la géolocalisation d'un 
> utilisateur, le RGPD dit que c'est une donnée privée et que l'accès à ces 
> données doit être protégé et réservé à cet utilisateur et non pas accessible 
> à n'importe qui visiterait une carte uMap publique. 
> Avant de permettre cela il faudrait qu'uMap accepte le principe d'héberger 
> des cartes à usage privé (demandant une authentification pour ensuite 
> accorder un accès). 
> 
> Le lun. 15 oct. 2018 à 19:10, Philippe Verdy  a écrit : 
> Je pense que c'est utile pour suivre sur uMap une carte d'itinéraire 
> spécifique en se repérant directement dessus. Et donc de pouvoir s'échanger 
> des itinéraires plus ou moins privés (par exemple poster un lien uMap via un 
> mail ou un SMS échangé entre deux personnes qui souhaitent s'aider au 
> guidage). 
> 
> L'itinéraire pourrait n'avoir un intérêt que purement temporaire et pour un 
> usage par une unique personne, la carte uMap étant ensuite supprimée par son 
> auteur (mais je ne pense pas qu'uMap soit fait pour échanger des itinéraires 
> privés, il doit être possible d'échanger un geoJSON ou un .kml et le charger 
> dans une application de navigation personnelle existante, qui l'affichera au 
> dessus de son fond de carte intégré; le principe d'uMap est plutôt de 
> cartographier des éléments spécifiques par n'importe qui, même dans un but 
> plus ou moins commercial, mais de rendre cela ensuite public sans avoir à 
> payer Google pour cela quand cela ne vise au final qu'un public assez limité, 
> mais sur une longue durée où ces cartes ont encore un intérêt, par exemple 
> des cartes touristiques ou documentant des articles de fonds historiques, 
> tels que des cartes de batailles militaires, des événements sportifs, etc.). 
> 
> Ceci dit uMap n'affichera pas votre orientation. Il faudrait une connexion 
> spécifique avec un objet utilisant l'API locale de géolocalisation, et une 
> permission spécifique supplémentaire (allant au delà de la seule 
> géolocalisation) permettant au site web de l'afficher (ou un javascript 
> exécuté localement mais dans le contexte de permission du domaine web dont il 
> provient et qui lui permet de justement manipuler le DOM de la page web 
> affichée, et non dans le contexte local) et de le mettre en jour en continu 
> (sans interaction nécessaire avec le serveur web). 
> 
> Ce peut être une extension comparable à celle d'une application de navigation 
> embarquée (sur un smartphone) ou un récepteur GPS de navigation. On peut 
> toujours demander si UMap veut proposer une telle extension (éventuellement 
> en développer une si ça n'existe pas encore en tant que composant 
> réutilisable ou si la réutilisation n'est pas compatible avec les termes du 
> site ou UMap est déployé) 
> 
> Le lun. 15 oct. 2018 à 16:16, Shohreh  a écrit : Yann 
> Schneylin wrote
>> J'aimerais que ma position GPS s'affiche sur la carte (comme on pourrait
>> le faire avec Google Maps par exemple). Est-ce possible ?
> 
> Quel est l'objectif final ?
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> 
> ___
> 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 

Links:
--
[1] http://www.euziere.org___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] boundary et addr:postcode / postal_code

[Ralf Treinen]

On Mon, Oct 15, 2018 at 08:08:18PM +, marc marc wrote:
> Le 15. 10. 18 à 21:48, Ralf Treinen a écrit :
> 
> > Le wiki semble indiquer que c'est postal_code [1].
> 
> oui. postal_code pour définir le code postal d'une étendue
> par opposition à addr:postcode pour définir le code postal
> d'une addr en particulier.

Merci pour cette confirmation. Et on est bien d'accord que quand
le postal_code est renseigné pour une étendu avec admin_level=9
(les arrondissements de Paris) qu'il n'est pas utile de le 
repeter sur les quartiers (adminlevel=10) inclus dans cet arrondissement ?

-Ralf.

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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[Paul Desgranges]

Bonsoir,


Le 14. 10. 18 à 22:12, Paul Desgranges a écrit :

/Un truc en plus, le terme 'piscine' de manière générale peut signifier à />>/la fois le bassin, le bâtiment, mais aussi le 
complexe sportif : />>/  - "leisure=swimming_pool" seul, donc ça serait le bassin, mais 
/>>/"leisure=swimming_pool" + "building=yes" là on parlerait du 'bâtiment />>/piscine'  (le bassin est 
alors parfois à l'extérieur) />

cette interprétation me semble erronée.
leisure=swimming_pool est selon moi clairement définit comme étant le bassin.
"leisure=swimming_pool" + "building=yes c'est donc un bassin "couvert" 
par un bâtiment. c'est assez rare mais j'en connais un : je suis passé 
plusieurs fois devant en me demandant si c'était un garage entière vitré 
ou une serre en dur... avant d'un jour apercevoir que l'intérieur est 
entièrement constitué d'un bassin d'eau (piscine privé).

si le bassin n'est pas dans le bâtiment, il faut selon moi 2 objets.


Ce n'est pas rare du tout :-) il y en a des centaines, si je l'ai dit c'est que 
j'avais regardé avant.
Je ne suis pas passé devant ;-) j'ai regardé icihttps://overpass-turbo.eu/s/CMB   
Les contributeurs ont assez largement utilisé cette façon pour mapper les piscines-bâtiments (bâtiments qui contiennent une piscine).

C'est effectivement une interprétation erronée, mais certainement pas de moi, 
des contributeurs plutôt
qui auraient dû mapper ça comme ça : "leisure=sports_centre" + "sport=swimming"
Ce que je voulais dire par => on a souvent le cas : "leisure=sports_centre" + "sport=swimming" = 
"leisure=swimming_pool" + "building=yes"



Salut,

Du coup, je pense qu'on peut imaginer un plan d'action comme ça :
- modification massive de amenity=swimming_pool vers 
leisure=swimming_pool comme proposé par Marc
- analyse Osmose qui vérifie la taille des leisure=swimming_pool et 
remonte un signalement quand c'est vraiment trop grand (en utilisant la 
formule de Jérôme)
- mission maproulette pour identifier des leisure=swimming_pool qui 
devraient en fait être des leisure=sports_centre


Pour le dernier point, j'ai l'impression qu'en cherchant les 
leisure=swimming_pool qui ont un tag name, on tombe principalement sur 
des éléments mal taggés qui devraient être des sports_centre, on doit 
pouvoir broder autour de ça pour Maproulette, même si on aura quelques 
faux positifs.

Oui, dans les trois cas ci-dessus on peut en trouver beaucoup déjà avec 
"leisure=swimming_pool" + "building=yes"



Qu'en dites-vous ?


Bien d'accord !
 
 --

Noémie Lehuby
Donc l'idée


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

Re: [OSM-talk-fr] [Tagging-fr] Vote ouvert pour la carto des réseaux télécoms

[Jean-Marc Liotier]

On 10/15/18 6:01 PM, François Lacombe wrote:
Ceci dit, en donnant assez de visibilité à nos activités, peut-être 
que les opérateurs seront motivés et comprendront le sens de tout ça, 
à suivre !


On peut toujours rêver...

Ceci dit, je suppose que la mention de GraceTHD dans ta présentation 
n'est pas innocente: s'il y a un espoir, il est du côté des 
collectivités locales, dont les intérêts ont des chances de finir par 
s'aligner sur un fonctionnement collaboratif.


J'imagine bien, pour les échanges inter-opérateurs, l'intérêt politique 
des collectivités locales d'avoir comme *_codeext un objet commun, 
neutre à tous points de vue et géré collectivement, au lieu d'utiliser 
les identifiants internes de $opérateur1, $opérateur2. Peut-être un 
montage analogue à la BAN ?



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

Re: [OSM-talk-fr] openinframap

[Vincent Privat]

Du coup je sais pas si c'est judicieux le label "Substation 20kv" pour tous
les postes sans nom. La carte au zoom 13 est saturée maintenant :D

Le lun. 15 oct. 2018 à 21:27, Laurent Combe  a
écrit :

> cool
>
> Le ven. 12 oct. 2018 à 13:39, François Lacombe 
> a écrit :
>
>> Bonjour
>>
>> Le serveur de tuiles d'OpenInfraMap est de nouveau opérationnel.
>> Les mises a jour ont été faites.
>>
>> François
>>
>> Le sam. 1 sept. 2018 à 12:23, François Lacombe 
>> a écrit :
>>
>>> Bonjour
>>>
>>> A noter que russs n'intervient sur openinframap qu'entre Noel et le
>>> nouvel an habituellement
>>>
>>> J'ai bien proposé de l'aider dans sa tache mais sans réponse. Il y a
>>> pourtant beaucoup à faire
>>>
>>> Bonne journée
>>>
>>> François
>>>
>>> Le sam. 1 sept. 2018 à 10:26, marc marc  a
>>> écrit :
>>>
 Bonjour,

 info de Gazer75 (qui ne parle pas français) sur irc :
 I think it has stopped due to a problem,
 but ru is quite busy atm.

 en français : il y a un problème :-)
 mais "russs", le gars qui s'en occupe, est débordé pour le moment.
 Le mieux est de prendre contact directement avec lui ou chercher s'ils
 ont un système de ticket pour être au courant des changements.

 Cordialement,
 Marc

 Le 01. 09. 18 à 08:44, Laurent Combe a écrit :
 > petit up gentil
 > le problème de rafraichissement semble toujours présent
 >
 > Le mer. 22 août 2018 à 21:34, François Lacombe
 > mailto:fl.infosrese...@gmail.com>> a
 écrit :
 >
 > Bonsoir,
 >
 > Relativement à ce problème, il semble toujours présent dans la
 zone
 > https://openinframap.org/#13/43.8486/1.4224/Power-Telecoms
 >
 > Il y a comme une espèce de ligne au nord de laquelle rien ne
 passe.
 > Surement un problème de mise à jour
 > A voir si les admins consentent à recharger la base
 >
 > François
 >
 > Le lun. 20 août 2018 à 08:48, François Lacombe
 > mailto:fl.infosrese...@gmail.com>> a
 écrit :
 >
 > Bonjour Laurent
 >
 > En effet, on dirait qu'il y a une ligne horizontale au nord de
 > laquelle il n'y a pas de postes ou de lignes
 >
 > On va attendre encore quelques jours pour voir si ca se
 débloque
 >
 > François
 >
 > Le lun. 20 août 2018 à 08:13, Laurent Combe
 > mailto:laurent.co...@free.fr>> a
 écrit :
 >
 > alors quelque chose m'échappe
 > au nord de toulouse, commune de Fronton par exemple , la
 > carte affichée par openinframap ne se réactualise plus
 > depuis qques jours
 > aucune nouvelle ligne electrique n'apparait dans ce
 secteur
 >
 > j'ai viré cookie, cache, ...
 >
 > je ne vois pas
 >
 > Laurent
 >
 >
 > Le dim. 19 août 2018 à 19:54, François Lacombe
 > >>> > > a écrit :
 >
 > Bonjour
 >
 > Environ 1 cache de 24h
 >
 > François
 >
 > Le dim. 19 août 2018 à 19:38, Laurent Combe
 > mailto:laurent.co...@free.fr>>
 a
 > écrit :
 >
 > Bonjour
 >
 > Savez-vous a quelle fréquence se regénère les
 tuiles
 > d'OpenInfraMap ?
 >
 > Laurent
 > ___
 > Talk-fr mailing list
 > Talk-fr@openstreetmap.org
 > 
 > https://lists.openstreetmap.org/listinfo/talk-fr
 >
 > ___
 > Talk-fr mailing list
 > Talk-fr@openstreetmap.org >>> Talk-fr@openstreetmap.org>
 > https://lists.openstreetmap.org/listinfo/talk-fr
 >
 > ___
 > Talk-fr mailing list
 > Talk-fr@openstreetmap.org >>> 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
 >

 ___
 Talk-fr mailing list

Re: [OSM-talk-fr] boundary et addr:postcode / postal_code

[marc marc]

Le 15. 10. 18 à 21:48, Ralf Treinen a écrit :

> Le wiki semble indiquer que c'est postal_code [1].

oui. postal_code pour définir le code postal d'une étendue
par opposition à addr:postcode pour définir le code postal
d'une addr en particulier.

> en région Parisienne je trouve addr:postcode utilisé

c'est une erreur très fréquente en France :-(

> JOSM n'est pas d'accord avec cette combinaison :
>suspicious tag combination - boundary together with addr:*

osmose non plus de mémoire :)

> Faut-il remplacer tout les addr:postcode par postal_code dans les
> limites des communes ou arrondissements ?

oui... et convaincre ceux qui ont déjà fait des opérations inverses
de le cesser.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Décalage cadastre

[Sébastien Dinot]

Bonsoir,

Valentin GAUTREAU a écrit :
> Je suis face à un dilemme pour plusieurs communes et particulièrement
> sur Montfaucon-Montigné (49). Le cadastre est complètement décalé par
> rapport à la réalité (c'est à dire les cartes IGN et la BD Ortho IGN).
> Comment faire ? Il faut décaler les bâtiments car ils chevauchent les
> routes ou laisser comme tel avec plusieurs mètres de différence.

Ce type de décalage est assez fréquent et, bien souvent, c'est le
cadastre qui a tort (il arrive même que les bâtiments soient mal
orientés).

Dans le cas présent, j'ai jeté un œil à l'endroit. Les repères
géodésiques de l'IGN et les quelques traces GPS existantes donnent
raison à la BDOrtho de l'IGN. Tu peux donc recaler le bâti sur la
BDOrtho. Attention cependant, il est fréquent que le décalage ne soit
pas homogène sur une commune, et même qu'il ne soit pas homogène sur un
gros bourg. De manière générale, les lotissements récents sont bien
mieux géoréférencés que le cœur historique des villages. Il faut donc
travailler groupe de bâtiments par groupe de bâtiments, voire procéder
à des ajustements individuels.

> Par ailleurs, peut-on informer les mairies de ces erreurs ?

À mon avis, c'est plutôt la DGFiP qu'il faudrait informer.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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

[OSM-talk-fr] boundary et addr:postcode / postal_code

[Ralf Treinen]

Bonjour,

quel tag faut-il utiliser pour le code postal d'une région (dans le
sens géométrique, pas administrative) délimitée par une boundary ?
Le wiki semble indiquer que c'est postal_code [1]. Par contre partout
où je regarde en région Parisienne je trouve addr:postcode utilisé 
à la place. JOSM n'est pas d'accord avec cette combinaison :

  suspicious tag combination - boundary together with addr:*

Faut-il remplacer tout les addr:postcode par postal_code dans les
limites des communes ou arrondissements ?

-Ralf.

[1] https://wiki.openstreetmap.org/wiki/Key:postal_code

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

Re: [OSM-talk-fr] Décalage cadastre

[marc marc]

Le 15. 10. 18 à 21:17, Valentin GAUTREAU a écrit :
> Je suis face à un dilemme pour plusieurs communes et particulièrement 
> sur Montfaucon-Montigné (49). Le cadastre est complètement décalé par 
> rapport à la réalité (c'est à dire les cartes IGN et la BD Ortho IGN). 
> Comment faire ? Il faut décaler les bâtiments car ils chevauchent les 
> routes ou laisser comme tel avec plusieurs mètres de différence.

il y a plusieurs "visions", selon la précision et le côté pratique :

l'idéal c'est de trouver un man_made=survey_point de l'ign, de vérifier 
dans son historique s'il n'a pas été bougé et d'aligner le tout dessus.
c'est "la vérité" normalement en matière de coordonnées.

Le plus commode c'est de s'aligner sur le cadastre tant que t'as pas 
finit d'importer les bâtiments.
Une fois les bâtiments finit, il faut s'aligner sur l'un, sur l'autre 
selon ce qui te semble le moins mauvais (sans avoir regardé ce cas là, 
j'aurais tendance à choisir la bdortho)

à plus long terme, si tu trouves pas de repère géodésique et si
c'est proche de chez toi, il faut x jours différents une trace gps
d'un élément très reconnaissable (ex une route avec angle à 90°
histoire d'ensuite faire la moyenne des différentes traces
(visuellement ou via stravia par ex) et caler le cadastre et/ou
la bdortho sur cette moyenne (on peux partager/sauver le décalage
avec josm)
et ensuite faut réaligner le tout... et cela c'est bcp moins marrant

> Par ailleurs, peut-on informer les mairies de ces erreurs ?

ho tu peux... mais met un cierge à Marie en même temps...
L'administration est trop souvent peu réceptive/réactive
aux remontées d'erreur... mais fait tenter... mais uniquement
après que tu ai identifié si c'est bien le cadastre qui est
réellement décalé ou pas...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] openinframap

[Laurent Combe]

cool

Le ven. 12 oct. 2018 à 13:39, François Lacombe 
a écrit :

> Bonjour
>
> Le serveur de tuiles d'OpenInfraMap est de nouveau opérationnel.
> Les mises a jour ont été faites.
>
> François
>
> Le sam. 1 sept. 2018 à 12:23, François Lacombe 
> a écrit :
>
>> Bonjour
>>
>> A noter que russs n'intervient sur openinframap qu'entre Noel et le
>> nouvel an habituellement
>>
>> J'ai bien proposé de l'aider dans sa tache mais sans réponse. Il y a
>> pourtant beaucoup à faire
>>
>> Bonne journée
>>
>> François
>>
>> Le sam. 1 sept. 2018 à 10:26, marc marc  a
>> écrit :
>>
>>> Bonjour,
>>>
>>> info de Gazer75 (qui ne parle pas français) sur irc :
>>> I think it has stopped due to a problem,
>>> but ru is quite busy atm.
>>>
>>> en français : il y a un problème :-)
>>> mais "russs", le gars qui s'en occupe, est débordé pour le moment.
>>> Le mieux est de prendre contact directement avec lui ou chercher s'ils
>>> ont un système de ticket pour être au courant des changements.
>>>
>>> Cordialement,
>>> Marc
>>>
>>> Le 01. 09. 18 à 08:44, Laurent Combe a écrit :
>>> > petit up gentil
>>> > le problème de rafraichissement semble toujours présent
>>> >
>>> > Le mer. 22 août 2018 à 21:34, François Lacombe
>>> > mailto:fl.infosrese...@gmail.com>> a
>>> écrit :
>>> >
>>> > Bonsoir,
>>> >
>>> > Relativement à ce problème, il semble toujours présent dans la zone
>>> > https://openinframap.org/#13/43.8486/1.4224/Power-Telecoms
>>> >
>>> > Il y a comme une espèce de ligne au nord de laquelle rien ne passe.
>>> > Surement un problème de mise à jour
>>> > A voir si les admins consentent à recharger la base
>>> >
>>> > François
>>> >
>>> > Le lun. 20 août 2018 à 08:48, François Lacombe
>>> > mailto:fl.infosrese...@gmail.com>> a
>>> écrit :
>>> >
>>> > Bonjour Laurent
>>> >
>>> > En effet, on dirait qu'il y a une ligne horizontale au nord de
>>> > laquelle il n'y a pas de postes ou de lignes
>>> >
>>> > On va attendre encore quelques jours pour voir si ca se
>>> débloque
>>> >
>>> > François
>>> >
>>> > Le lun. 20 août 2018 à 08:13, Laurent Combe
>>> > mailto:laurent.co...@free.fr>> a
>>> écrit :
>>> >
>>> > alors quelque chose m'échappe
>>> > au nord de toulouse, commune de Fronton par exemple , la
>>> > carte affichée par openinframap ne se réactualise plus
>>> > depuis qques jours
>>> > aucune nouvelle ligne electrique n'apparait dans ce secteur
>>> >
>>> > j'ai viré cookie, cache, ...
>>> >
>>> > je ne vois pas
>>> >
>>> > Laurent
>>> >
>>> >
>>> > Le dim. 19 août 2018 à 19:54, François Lacombe
>>> > >> > > a écrit :
>>> >
>>> > Bonjour
>>> >
>>> > Environ 1 cache de 24h
>>> >
>>> > François
>>> >
>>> > Le dim. 19 août 2018 à 19:38, Laurent Combe
>>> > mailto:laurent.co...@free.fr>>
>>> a
>>> > écrit :
>>> >
>>> > Bonjour
>>> >
>>> > Savez-vous a quelle fréquence se regénère les
>>> tuiles
>>> > d'OpenInfraMap ?
>>> >
>>> > Laurent
>>> > ___
>>> > Talk-fr mailing list
>>> > Talk-fr@openstreetmap.org
>>> > 
>>> > https://lists.openstreetmap.org/listinfo/talk-fr
>>> >
>>> > ___
>>> > Talk-fr mailing list
>>> > Talk-fr@openstreetmap.org >> Talk-fr@openstreetmap.org>
>>> > https://lists.openstreetmap.org/listinfo/talk-fr
>>> >
>>> > ___
>>> > Talk-fr mailing list
>>> > Talk-fr@openstreetmap.org >> 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
>>> >
>>>
>>> ___
>>> 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

[OSM-talk-fr] Décalage cadastre

[Valentin GAUTREAU]

Bonjour à tous !

Je suis face à un dilemme pour plusieurs communes et particulièrement 
sur Montfaucon-Montigné (49). Le cadastre est complètement décalé par 
rapport à la réalité (c'est à dire les cartes IGN et la BD Ortho IGN). 
Comment faire ? Il faut décaler les bâtiments car ils chevauchent les 
routes ou laisser comme tel avec plusieurs mètres de différence.


Par ailleurs, peut-on informer les mairies de ces erreurs ?

Cordialement,

Valentin


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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[Noémie Lehuby]

Salut,

Du coup, je pense qu'on peut imaginer un plan d'action comme ça :
- modification massive de amenity=swimming_pool vers 
leisure=swimming_pool comme proposé par Marc
- analyse Osmose qui vérifie la taille des leisure=swimming_pool et 
remonte un signalement quand c'est vraiment trop grand (en utilisant la 
formule de Jérôme)
- mission maproulette pour identifier des leisure=swimming_pool qui 
devraient en fait être des leisure=sports_centre


Pour le dernier point, j'ai l'impression qu'en cherchant les 
leisure=swimming_pool qui ont un tag name, on tombe principalement sur 
des éléments mal taggés qui devraient être des sports_centre, on doit 
pouvoir broder autour de ça pour Maproulette, même si on aura quelques 
faux positifs.


Qu'en dites-vous ?

--
Noémie Lehuby

Le 15/10/2018 à 01:11, Jérôme Amagat a écrit :
leisure=swimming_pool c'est le bassin seulement (comme leisure=pich 
est juste le terrain qui est assez souvent à l’intérieur d'un 
"complexe sportif" ou "stade" ... qui se tag aussi leisure=sports_centre)


il peut y avoir d'autre sport pratiqué dans les piscines municipales 
et les autres piscine accessible au public et donc il peut y avoir 
plusieurs choses dans sport=* en plus de swimming. les différents 
sports doivent être séparés par des points virgules par exemple 
sport=swimming;scuba_diving quand on peut faire de la plongée.


amenity=swimming_pool ne doit plus être utiliser et n'est plus visible 
sur le rendu de base.

ça serait pas mal de les faire disparaître de france.

Pour trouver des piscines qui ne sont pas qu'un bassin, on peut 
chercher les amenity=swimming_pool (et les leisure=swimming_pool) les 
plus grandes avec josm.
obtenir les piscines avec overpass turbo ( 
https://overpass-turbo.eu/s/CL0 ) et faire une recherche ctrl + F : 
amenity=swimming_pool  areasize:2000-
on peut bien sur changer le 2000 que j'ai mis et ça ne marche pas si 
ce n'est qu"un node :)





___
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] représentation 3d des olympiades

[Nicolas Bétheuil]

Du coup j'ai plutôt utilisé area=yes & pedestrian=yes et j'ai enlevé le
fait que c'était un immeuble
https://www.openstreetmap.org/changeset/63551936


Le lun. 15 oct. 2018 à 18:15, Philippe Verdy  a écrit :

> N'est-ce pas le même problème sur d'autres "dalles" comme celle de la
> Défense à Courbevoie, ou la dalle du Colombier à Rennes ? Et le même
> problème dans toutes les villes construites sur des reliefs escarpés (comme
> Monaco), où il est difficile de dire quel est le niveau du "sol" pour un
> étage donné qui peut être sous-terrain ou en hauteur d'un autre côté avec
> d'autres niveaux intercalaires?
>
> La notion de "niveau" (ou "étage") se gère à priori bâtiment par bâtiment,
> pourtant on trouve des cas où deux batiments contruits sur des sols
> différents ont des passages accolés au même niveau (on passe san monter ou
> descendre du rez-de chaussée de l'un au 3e étage de l'autre) et on en
> trouve même dans des villes réputées "plates" comme Paris (les "grands
> magasins") ou Lille (par exemple sa fameuse grande librairie) qui ont aussi
> réunit des niveaux différents de plusieurs bâtiments accolés (ou assez
> proches pour installer des passerelles).
>
> Dans certains cas, au sein de ces batiments, la notion de "niveau" n'est
> pas la même entre les surfaces occupées par un même magasin ou une même
> entreprise, que celle d'étage au sein des batiments dans lesquels ces
> locaux sont situés.
>
> On a le cas aussi avec les stations souterraines de train ou métro, où la
> notion de niveau n'est pas beaucoup plus simple (le même niveau peut
> pourtant avoir des altitudes de plancher variables, avec des pentes douces
> ou quelques marches ignorées et sur une longueur assez grande cela fait
> vite une différence).
>
> Le tag "layer=n" d'OSM ne donne qu'une relation d'ordre relatif entre des
> éléments superposés à la même position géographique (longitude et
> latitude), le tag "level=n" dans un batiment peut ne pas suffire non plus,
> et il est difficile de taguer précisément tous les points avec une
> véritable altitude, à moins de décider de ne plus taguer ça dans OSM
>
> Mais on peut le faire avec un véritable modèle 3D (hors d'OSM lui-même)
> pour l'ensemble d'un édifice, qu'on géolocalisera ensuite sur un seul point
> (avec aussi son orientation correcte) ; et alors dans OMS on se contentera
> de tracer la seule empreinte au sol, quel que soit son altitude. Mais il
> manquera alors dans OSM les "ways" de communication (on mes ajoute de façon
> approximative sans tenir compte de l'altitude, mais en les ordonnant avec
> "layer=n", le reste est trop difficile à modéliser avec le modèle 2D d'OSM
> qui n'est pas conçu pour gérer correctement la 3e dimension).
>
>
>
> Le lun. 15 oct. 2018 à 17:40, Nicolas Bétheuil  a
> écrit :
>
>> Tout le monde se sera bien entendu rendu compte qu'il n'y a pas de 3d
>> dans mapcontrib mais plutôt streetcomplete.
>>
>> My bad, Désolé pardon plates excuses confusantes.
>>
>> Le lun. 15 oct. 2018 13:58, Nicolas Bétheuil  a
>> écrit :
>>
>>> Bonjour,
>>>
>>> En me baladant hier, je suis passé dans le 13ème à faire un peu de
>>> MapContrib
>>> Le rendu 3d est vraiment pas terrible
>>> https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30
>>>
>>> Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle
>>> faisait 20 étages et du coup les commerces présents sur la dalle sont juste
>>> invisible.
>>>
>>> Vous auriez une idée de comment améliorer ça ?
>>>
>> ___
>> 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] Problème îlot et doublon relation ?

[Jérôme Amagat]

Le lun. 15 oct. 2018 à 13:29, Waxy  a écrit :

> Salut,
>
> J'ai modifié un îlot, pour l'enceindre d'un lagon et il n'est plus rendu
> sur les cartes.
> Même si on n'étiquette pas pour le rendu je soupçonne un problème parce
> que j'ai étiqueté de la même manière que d'autres îlots qui sont bien
> rendus ! J'ai dû merder à un moment mais je sais pas quand 
>
> - L'îlot de Pamandzi mal rendu est au sein de la relation 8 801 671
> - Exemple d'îlots correctement rendus : îles Choazil, relation 8 789 735
>
> Je pense qu'il n'y a pas de problème. Par contre la partie bleu de l’océan
qui est obtenu grâce au tag natural=coastline est très longue à se mettre à
jour. Je ne sais pas du tout comment ça marche mais j'ai déjà eu le même
problème et je pense que ce bleu se mettra a jour d'ici 1 ou 2 semaines.
(une autre solution c'est de mettre une autre couleur par dessus en
ajoutant un landuse=*, mais on tag pas pour le rendu donc il faut choisir
le bon landuse :) )


> Par ailleurs n'y a-t-il pas doublon entre les relations 1 363 069 et 3
> 388 394 ?
>
> Une des relations c'est pour le département de Mayotte et l'autre pour la
région. il y a la même chose dans les 2 relations vu que Mayotte est à la
fois un département et une région mais il y a des tags différents,
admin_level=4 et admin_level=6 surtout.


> @+
>
> ___
> 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] Afficher sa position GPS sur une carte uMap

[Philippe Verdy]

Note: une telle extension posera des problèmes légaux en Europe vis-à-vis
du RGPD : en effet si elle colelcte en continu la géolocalisation d'un
utilisateur, le RGPD dit que c'est une donnée privée et que l'accès à ces
données doit être protégé et réservé à cet utilisateur et non pas
accessible à n'importe qui visiterait une carte uMap publique.
Avant de permettre cela il faudrait qu'uMap accepte le principe d'héberger
des cartes à usage privé (demandant une authentification pour ensuite
accorder un accès).


Le lun. 15 oct. 2018 à 19:10, Philippe Verdy  a écrit :

> Je pense que c'est utile pour suivre sur uMap une carte d'itinéraire
> spécifique en se repérant directement dessus. Et donc de pouvoir s'échanger
> des itinéraires plus ou moins privés (par exemple poster un lien uMap via
> un mail ou un SMS échangé entre deux personnes qui souhaitent s'aider au
> guidage).
>
> L'itinéraire pourrait n'avoir un intérêt que purement temporaire et pour
> un usage par une unique personne, la carte uMap étant ensuite supprimée par
> son auteur (mais je ne pense pas qu'uMap soit fait pour échanger des
> itinéraires privés, il doit être possible d'échanger un geoJSON ou un .kml
> et le charger dans une application de navigation personnelle existante, qui
> l'affichera au dessus de son fond de carte intégré; le principe d'uMap est
> plutôt de cartographier des éléments spécifiques par n'importe qui, même
> dans un but plus ou moins commercial, mais de rendre cela ensuite public
> sans avoir à payer Google pour cela quand cela ne vise au final qu'un
> public assez limité, mais sur une longue durée où ces cartes ont encore un
> intérêt, par exemple des cartes touristiques ou documentant des articles de
> fonds historiques, tels que des cartes de batailles militaires, des
> événements sportifs, etc.).
>
> Ceci dit uMap n'affichera pas votre orientation. Il faudrait une connexion
> spécifique avec un objet utilisant l'API locale de géolocalisation, et une
> permission spécifique supplémentaire (allant au delà de la seule
> géolocalisation) permettant au site web de l'afficher (ou un javascript
> exécuté localement mais dans le contexte de permission du domaine web dont
> il provient et qui lui permet de justement manipuler le DOM de la page web
> affichée, et non dans le contexte local) et de le mettre en jour en continu
> (sans interaction nécessaire avec le serveur web).
>
> Ce peut être une extension comparable à celle d'une application de
> navigation embarquée (sur un smartphone) ou un récepteur GPS de navigation.
> On peut toujours demander si UMap veut proposer une telle extension
> (éventuellement en développer une si ça n'existe pas encore en tant que
> composant réutilisable ou si la réutilisation n'est pas compatible avec les
> termes du site ou UMap est déployé)
>
>
> Le lun. 15 oct. 2018 à 16:16, Shohreh  a écrit :
>
>> Yann Schneylin wrote
>> > J’aimerais que ma position GPS s’affiche sur la carte (comme on pourrait
>> > le faire avec Google Maps par exemple). Est-ce possible ?
>>
>> Quel est l'objectif final ?
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>>
>> ___
>> 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] Afficher sa position GPS sur une carte uMap

[Philippe Verdy]

Je pense que c'est utile pour suivre sur uMap une carte d'itinéraire
spécifique en se repérant directement dessus. Et donc de pouvoir s'échanger
des itinéraires plus ou moins privés (par exemple poster un lien uMap via
un mail ou un SMS échangé entre deux personnes qui souhaitent s'aider au
guidage).

L'itinéraire pourrait n'avoir un intérêt que purement temporaire et pour un
usage par une unique personne, la carte uMap étant ensuite supprimée par
son auteur (mais je ne pense pas qu'uMap soit fait pour échanger des
itinéraires privés, il doit être possible d'échanger un geoJSON ou un .kml
et le charger dans une application de navigation personnelle existante, qui
l'affichera au dessus de son fond de carte intégré; le principe d'uMap est
plutôt de cartographier des éléments spécifiques par n'importe qui, même
dans un but plus ou moins commercial, mais de rendre cela ensuite public
sans avoir à payer Google pour cela quand cela ne vise au final qu'un
public assez limité, mais sur une longue durée où ces cartes ont encore un
intérêt, par exemple des cartes touristiques ou documentant des articles de
fonds historiques, tels que des cartes de batailles militaires, des
événements sportifs, etc.).

Ceci dit uMap n'affichera pas votre orientation. Il faudrait une connexion
spécifique avec un objet utilisant l'API locale de géolocalisation, et une
permission spécifique supplémentaire (allant au delà de la seule
géolocalisation) permettant au site web de l'afficher (ou un javascript
exécuté localement mais dans le contexte de permission du domaine web dont
il provient et qui lui permet de justement manipuler le DOM de la page web
affichée, et non dans le contexte local) et de le mettre en jour en continu
(sans interaction nécessaire avec le serveur web).

Ce peut être une extension comparable à celle d'une application de
navigation embarquée (sur un smartphone) ou un récepteur GPS de navigation.
On peut toujours demander si UMap veut proposer une telle extension
(éventuellement en développer une si ça n'existe pas encore en tant que
composant réutilisable ou si la réutilisation n'est pas compatible avec les
termes du site ou UMap est déployé)


Le lun. 15 oct. 2018 à 16:16, Shohreh  a écrit :

> Yann Schneylin wrote
> > J’aimerais que ma position GPS s’affiche sur la carte (comme on pourrait
> > le faire avec Google Maps par exemple). Est-ce possible ?
>
> Quel est l'objectif final ?
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] représentation 3d des olympiades

[Philippe Verdy]

N'est-ce pas le même problème sur d'autres "dalles" comme celle de la
Défense à Courbevoie, ou la dalle du Colombier à Rennes ? Et le même
problème dans toutes les villes construites sur des reliefs escarpés (comme
Monaco), où il est difficile de dire quel est le niveau du "sol" pour un
étage donné qui peut être sous-terrain ou en hauteur d'un autre côté avec
d'autres niveaux intercalaires?

La notion de "niveau" (ou "étage") se gère à priori bâtiment par bâtiment,
pourtant on trouve des cas où deux batiments contruits sur des sols
différents ont des passages accolés au même niveau (on passe san monter ou
descendre du rez-de chaussée de l'un au 3e étage de l'autre) et on en
trouve même dans des villes réputées "plates" comme Paris (les "grands
magasins") ou Lille (par exemple sa fameuse grande librairie) qui ont aussi
réunit des niveaux différents de plusieurs bâtiments accolés (ou assez
proches pour installer des passerelles).

Dans certains cas, au sein de ces batiments, la notion de "niveau" n'est
pas la même entre les surfaces occupées par un même magasin ou une même
entreprise, que celle d'étage au sein des batiments dans lesquels ces
locaux sont situés.

On a le cas aussi avec les stations souterraines de train ou métro, où la
notion de niveau n'est pas beaucoup plus simple (le même niveau peut
pourtant avoir des altitudes de plancher variables, avec des pentes douces
ou quelques marches ignorées et sur une longueur assez grande cela fait
vite une différence).

Le tag "layer=n" d'OSM ne donne qu'une relation d'ordre relatif entre des
éléments superposés à la même position géographique (longitude et
latitude), le tag "level=n" dans un batiment peut ne pas suffire non plus,
et il est difficile de taguer précisément tous les points avec une
véritable altitude, à moins de décider de ne plus taguer ça dans OSM

Mais on peut le faire avec un véritable modèle 3D (hors d'OSM lui-même)
pour l'ensemble d'un édifice, qu'on géolocalisera ensuite sur un seul point
(avec aussi son orientation correcte) ; et alors dans OMS on se contentera
de tracer la seule empreinte au sol, quel que soit son altitude. Mais il
manquera alors dans OSM les "ways" de communication (on mes ajoute de façon
approximative sans tenir compte de l'altitude, mais en les ordonnant avec
"layer=n", le reste est trop difficile à modéliser avec le modèle 2D d'OSM
qui n'est pas conçu pour gérer correctement la 3e dimension).



Le lun. 15 oct. 2018 à 17:40, Nicolas Bétheuil  a écrit :

> Tout le monde se sera bien entendu rendu compte qu'il n'y a pas de 3d dans
> mapcontrib mais plutôt streetcomplete.
>
> My bad, Désolé pardon plates excuses confusantes.
>
> Le lun. 15 oct. 2018 13:58, Nicolas Bétheuil  a écrit :
>
>> Bonjour,
>>
>> En me baladant hier, je suis passé dans le 13ème à faire un peu de
>> MapContrib
>> Le rendu 3d est vraiment pas terrible
>> https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30
>>
>> Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle
>> faisait 20 étages et du coup les commerces présents sur la dalle sont juste
>> invisible.
>>
>> Vous auriez une idée de comment améliorer ça ?
>>
> ___
> 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] [Tagging-fr] Vote ouvert pour la carto des réseaux télécoms

[François Lacombe]

Merci Séverin,

L'opendata dans les télécom arrive mais n'est pas encore très abouti dans
le domaine de l'infrastructure (tout ça est tellement secret)
Le but était de préparer le terrain pour d'éventuelles données libérées
dans le futur.
Il n'y a pas de projet de la part des opérateurs pour l'instant, il y a
surtout de la collecte terrain de la part de volontaires à qui il faut bien
donner un cadre.
Ceci dit, en donnant assez de visibilité à nos activités, peut-être que les
opérateurs seront motivés et comprendront le sens de tout ça, à suivre !

François

Le lun. 15 oct. 2018 à 17:50, Severin Menard  a
écrit :

> Merci François, définitivement maître ès réseaux, pour progressivement
> renforcer le tagging OSM et pour cette nouvelle contribution toujours
> particulièrement bien documentée et rendant le sujet compréhensible pour
> les non-initiés.
> Juste une question : ce tagging une fois adopté va porter un import de
> données émanant des sociétés de telecom, notamment dans le cadre français ?
> L'idée est que de valider d'abord le tagging pour ce type d'objet avant de
> s'attaquer à cet (ces ?) import(s) ?
>
> Séverin
>
> Le sam. 13 oct. 2018 à 13:35, François Lacombe 
> a écrit :
>
>> Bonjour à tous
>>
>> La rédaction de cette proposition était en cours depuis 2015, la voila
>> maintenant ouverte au vote. On a fini de l'écrire à 3 mains, traduite en
>> français:
>>
>> https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Telecom_local_loop
>>
>> On propose d'utiliser telecom=* pour cartographier les boucles locales
>> (la partie du réseau entre l'abonné et les premiers équipements de service
>> actif chez l'opérateur telecom) optiques ou cuivres.
>> telecom=* pourra avoir plus de valeurs décrites dans le futur, moyennant
>> plusieurs autres propositions à venir.
>> On va pouvoir nettoyer man_made de valeurs trop spécifiques aux télécoms.
>>
>> La version française intègre aussi nativement une correspondance avec le
>> modèle de données GraceTHD, qui est le format d'échange de référence
>> Covadis pour les réseaux télécoms (principalement optique). Le modèle d'OSM
>> proposé est totalement compatible, nous assurant ainsi une pérennité et
>> visibilité supplémentaires auprès des professionnels du secteur.
>>
>> Évidemment, ces tags sont prévus pour ajouter à OSM des données
>> publiquement accessibles. ne pas avoir de données disponibles ne rend pas
>> nécessairement la sémantique du modèle mauvaise.
>> On a pu le tester en France sur les réseaux fibres et cuivre sans
>> problèmes rencontrés.
>>
>> Merci de prendre quelques minutes pour placer un vote en bas de la
>> version anglaise
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop#Voting
>>
>> Bon weekend
>>
>> François
>> ___
>> Tagging-fr mailing list
>> tagging...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging-fr
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Tagging-fr] Vote ouvert pour la carto des réseaux télécoms

[Severin Menard]

Merci François, définitivement maître ès réseaux, pour progressivement
renforcer le tagging OSM et pour cette nouvelle contribution toujours
particulièrement bien documentée et rendant le sujet compréhensible pour
les non-initiés.
Juste une question : ce tagging une fois adopté va porter un import de
données émanant des sociétés de telecom, notamment dans le cadre français ?
L'idée est que de valider d'abord le tagging pour ce type d'objet avant de
s'attaquer à cet (ces ?) import(s) ?

Séverin

Le sam. 13 oct. 2018 à 13:35, François Lacombe 
a écrit :

> Bonjour à tous
>
> La rédaction de cette proposition était en cours depuis 2015, la voila
> maintenant ouverte au vote. On a fini de l'écrire à 3 mains, traduite en
> français:
> https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Telecom_local_loop
>
> On propose d'utiliser telecom=* pour cartographier les boucles locales (la
> partie du réseau entre l'abonné et les premiers équipements de service
> actif chez l'opérateur telecom) optiques ou cuivres.
> telecom=* pourra avoir plus de valeurs décrites dans le futur, moyennant
> plusieurs autres propositions à venir.
> On va pouvoir nettoyer man_made de valeurs trop spécifiques aux télécoms.
>
> La version française intègre aussi nativement une correspondance avec le
> modèle de données GraceTHD, qui est le format d'échange de référence
> Covadis pour les réseaux télécoms (principalement optique). Le modèle d'OSM
> proposé est totalement compatible, nous assurant ainsi une pérennité et
> visibilité supplémentaires auprès des professionnels du secteur.
>
> Évidemment, ces tags sont prévus pour ajouter à OSM des données
> publiquement accessibles. ne pas avoir de données disponibles ne rend pas
> nécessairement la sémantique du modèle mauvaise.
> On a pu le tester en France sur les réseaux fibres et cuivre sans
> problèmes rencontrés.
>
> Merci de prendre quelques minutes pour placer un vote en bas de la version
> anglaise
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop#Voting
>
> Bon weekend
>
> François
> ___
> Tagging-fr mailing list
> tagging...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] représentation 3d des olympiades

[Nicolas Bétheuil]

Tout le monde se sera bien entendu rendu compte qu'il n'y a pas de 3d dans
mapcontrib mais plutôt streetcomplete.

My bad, Désolé pardon plates excuses confusantes.

Le lun. 15 oct. 2018 13:58, Nicolas Bétheuil  a écrit :

> Bonjour,
>
> En me baladant hier, je suis passé dans le 13ème à faire un peu de
> MapContrib
> Le rendu 3d est vraiment pas terrible
> https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30
>
> Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle
> faisait 20 étages et du coup les commerces présents sur la dalle sont juste
> invisible.
>
> Vous auriez une idée de comment améliorer ça ?
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] représentation 3d des olympiades

[Nicolas Bétheuil]

en faite, le soucis ne sont pas les bâtiments qui ont des "sous-sol" mais
la dalle qui est notée comme un immeuble de 19 étages.

Le lun. 15 oct. 2018 à 15:58, Rpnpif  a écrit :

> Le 15 octobre 2018, Nicolas Bétheuil a écrit :
>
> > j'ai regardé dans ID directement et pas regardé les objets, du coup j'ai
> > rien vu
> >
> > ok, building:levels=19 est faux, il n'y a pas d'étage à proprement parlé
> > sous la dalle
> > et tous les building:levels sont donné avec comme point 0 le niveau de la
> > dalle et non la rue
> >
> > https://www.wikiwand.com/fr/Dalle_des_Olympiades
> >
> > du coup je ferais bien sauter le building:levels
> >
> > Vous en pensez quoi ?
>
> Ou plutôt appliquer ça :
> https://wiki.openstreetmap.org/wiki/FR:Key:building:levels?uselang=fr
>
> --
> Alain Rpnpif
>
> ___
> 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] Afficher sa position GPS sur une carte uMap

[Shohreh]

Yann Schneylin wrote
> J’aimerais que ma position GPS s’affiche sur la carte (comme on pourrait
> le faire avec Google Maps par exemple). Est-ce possible ?

Quel est l'objectif final ?




--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] représentation 3d des olympiades

[Nicolas Bétheuil]

C'est le même principe que Beaugrenelle dans le 15ème à Paris
http://demo.f4map.com/#lat=48.8507463=2.2850715=18
Une dalle au dessus du niveau du sol assez haute pour que des camions
passent dessous (3.5m de hauteur max)
une rue souterraine, mais qui commence par monter (angle rue du javelot /
depuis la rue de tolbiac) (je vous laisse allez sur un street view, pas
trouvé de photos libre du coin. va falloir que j'y retourne)
Des tours posées au dessus avec des échoppes de juste un rez de chaussé ou
deux niveaux.

Tout dépends de ce que l'on appelle sous-sol. le sol est haut par là, deux
escaliers mécanique pour y grimper.



Le lun. 15 oct. 2018 à 15:30, Leni  a écrit :

> Je ne connais pas l'endroit, mais si je comprends ton mail il s'agit d'une
> dalle avec des niveaux en sous-sol.
> Si je lis le wiki,
> https://wiki.openstreetmap.org/wiki/FR:Key:building:levels?uselang=fr
> "building:levels=19" veut dire un immeuble de 19 étages au dessus du sol.
> Si c'est une dalle au 2eme et que les niveaux sont en sous-sol il me
> semble que ce serait plutôt "building:levels:underground=17" +
> "building:levels=2"
>
> Cordialement
> Leni
>
>
>  Message original 
> De: marc marc 
> Envoyé: Mon Oct 15 14:50:04 GMT+02:00 2018
> À: "talk-fr@openstreetmap.org" 
> Sujet: Re: [OSM-talk-fr] représentation 3d des olympiades
>
> Le 15. 10. 18 à 13:58, Nicolas Bétheuil a écrit :
> > https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30
> >
> > Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle
> > faisait 20 étages et du coup les commerces présents sur la dalle sont
> > juste invisible.
>
> je connais pas vraiment le lieu
> mais je ne qualifierais pas la date de bâtiment
> https://www.openstreetmap.org/way/79084943
> mais je ne sais pas comment je la qualifierais mieux :)
> si j'ai bien décodé, c'est un parking souterrain
> avec une "square" principalement bétonné au dessus
> ___
> 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] représentation 3d des olympiades

[Rpnpif]

Le 15 octobre 2018, Nicolas Bétheuil a écrit :

> j'ai regardé dans ID directement et pas regardé les objets, du coup j'ai
> rien vu
> 
> ok, building:levels=19 est faux, il n'y a pas d'étage à proprement parlé
> sous la dalle
> et tous les building:levels sont donné avec comme point 0 le niveau de la
> dalle et non la rue
> 
> https://www.wikiwand.com/fr/Dalle_des_Olympiades
> 
> du coup je ferais bien sauter le building:levels
> 
> Vous en pensez quoi ?

Ou plutôt appliquer ça :
https://wiki.openstreetmap.org/wiki/FR:Key:building:levels?uselang=fr

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] représentation 3d des olympiades

[Nicolas Bétheuil]

j'ai regardé dans ID directement et pas regardé les objets, du coup j'ai
rien vu

ok, building:levels=19 est faux, il n'y a pas d'étage à proprement parlé
sous la dalle
et tous les building:levels sont donné avec comme point 0 le niveau de la
dalle et non la rue

https://www.wikiwand.com/fr/Dalle_des_Olympiades

du coup je ferais bien sauter le building:levels

Vous en pensez quoi ?

Le lun. 15 oct. 2018 à 14:50, marc marc  a
écrit :

> Le 15. 10. 18 à 13:58, Nicolas Bétheuil a écrit :
> > https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30
> >
> > Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle
> > faisait 20 étages et du coup les commerces présents sur la dalle sont
> > juste invisible.
>
> je connais pas vraiment le lieu
> mais je ne qualifierais pas la date de bâtiment
> https://www.openstreetmap.org/way/79084943
> mais je ne sais pas comment je la qualifierais mieux :)
> si j'ai bien décodé, c'est un parking souterrain
> avec une "square" principalement bétonné au dessus
> ___
> 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] représentation 3d des olympiades

[Leni]

Je ne connais pas l'endroit, mais si je comprends ton mail il s'agit d'une 
dalle avec des niveaux en sous-sol.
Si je lis le wiki, 
https://wiki.openstreetmap.org/wiki/FR:Key:building:levels?uselang=fr
"building:levels=19" veut dire un immeuble de 19 étages au dessus du sol.
Si c'est une dalle au 2eme et que les niveaux sont en sous-sol il me semble que 
ce serait plutôt "building:levels:underground=17" +  "building:levels=2" 

Cordialement 
Leni 


 Message original 
De: marc marc 
Envoyé: Mon Oct 15 14:50:04 GMT+02:00 2018
À: "talk-fr@openstreetmap.org" 
Sujet: Re: [OSM-talk-fr] représentation 3d des olympiades

Le 15. 10. 18 à 13:58, Nicolas Bétheuil a écrit :
> https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30
> 
> Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle 
> faisait 20 étages et du coup les commerces présents sur la dalle sont 
> juste invisible.

je connais pas vraiment le lieu
mais je ne qualifierais pas la date de bâtiment
https://www.openstreetmap.org/way/79084943
mais je ne sais pas comment je la qualifierais mieux :)
si j'ai bien décodé, c'est un parking souterrain
avec une "square" principalement bétonné au dessus
___
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] Afficher sa position GPS sur une carte uMap

[deuzeffe]

On 10/15/18 10:39 AM, Yann Schneylin wrote:

Bonjour à tous,


Bonjour,

Imaginons : je consulte une carte *umap* sur le terrain avec mon 
smartphone (ou tablette), en ayant pris soin d’activer le GPS. Disons 
celle-ci :


https://umap.openstreetmap.fr/fr/map/carte-des-capitelles_39012#11/43.6828/3.8768 



J’aimerais que ma position GPS s’affiche sur la carte (comme on pourrait 
le faire avec Google Maps par exemple). Est-ce possible ???


J’étais persuadé que oui, jusqu’à ce que je teste la manipulation la 
semaine dernière. Je n’y suis pas arrivé. Je pensais que le bouton 
''cible'' servait à ça.




J’ai essayé plusieurs navigateurs Androïd : Samsung Internet, Firefox, 
Google Chrome.

Je n’ai pas trouvé la réponse sur le net.


Un rapport avec ça : https://github.com/umap-project/umap/issues/634 ?

--
deuzeffe

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

Re: [OSM-talk-fr] représentation 3d des olympiades

[marc marc]

Le 15. 10. 18 à 13:58, Nicolas Bétheuil a écrit :
> https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30
> 
> Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle 
> faisait 20 étages et du coup les commerces présents sur la dalle sont 
> juste invisible.

je connais pas vraiment le lieu
mais je ne qualifierais pas la date de bâtiment
https://www.openstreetmap.org/way/79084943
mais je ne sais pas comment je la qualifierais mieux :)
si j'ai bien décodé, c'est un parking souterrain
avec une "square" principalement bétonné au dessus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] représentation 3d des olympiades

[Nicolas Bétheuil]

Bonjour,

En me baladant hier, je suis passé dans le 13ème à faire un peu de
MapContrib
Le rendu 3d est vraiment pas terrible
https://osmbuildings.org/?lat=48.82604=2.36646=17.2=30

Il y a bien level: 2 pour la dalle mais il dessine comme si la dalle
faisait 20 étages et du coup les commerces présents sur la dalle sont juste
invisible.

Vous auriez une idée de comment améliorer ça ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Problème îlot et doublon relation ?

[Waxy]

Salut,

J'ai modifié un îlot, pour l'enceindre d'un lagon et il n'est plus rendu
sur les cartes.
Même si on n'étiquette pas pour le rendu je soupçonne un problème parce
que j'ai étiqueté de la même manière que d'autres îlots qui sont bien
rendus ! J'ai dû merder à un moment mais je sais pas quand 

- L'îlot de Pamandzi mal rendu est au sein de la relation 8 801 671
- Exemple d'îlots correctement rendus : îles Choazil, relation 8 789 735

Par ailleurs n'y a-t-il pas doublon entre les relations 1 363 069 et 3
388 394 ?

@+

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

[OSM-talk-fr] Afficher sa position GPS sur une carte uMap

[Yann Schneylin]

Bonjour à tous,

Imaginons : je consulte une carte *umap* sur le terrain avec mon 
smartphone (ou tablette), en ayant pris soin d’activer le GPS. Disons 
celle-ci :


https://umap.openstreetmap.fr/fr/map/carte-des-capitelles_39012#11/43.6828/3.8768

J’aimerais que ma position GPS s’affiche sur la carte (comme on pourrait 
le faire avec Google Maps par exemple). Est-ce possible ???


J’étais persuadé que oui, jusqu’à ce que je teste la manipulation la 
semaine dernière. Je n’y suis pas arrivé. Je pensais que le bouton 
''cible'' servait à ça.




J’ai essayé plusieurs navigateurs Androïd : Samsung Internet, Firefox, 
Google Chrome.

Je n’ai pas trouvé la réponse sur le net.

Merci pour vos retours d’expérience,

*Yann Schneylin

Les Écologistes de l'Euzière*
/Domaine de Restinclières
34730 PRADES-LE-LEZ/
Standard : 04 67 59 54 62
Ligne directe : 04 67 06 83 40
yann.schney...@euziere.org 
www.euziere.org  | Facebook 

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