Re: [OSM-talk-fr] takeout Mapillary... déjà 2To et 1.5 million de photos

2020-07-01 Par sujet Jacques Lavignotte 



Le 01/07/2020 à 23:47, Frédéric Rodrigo a écrit :


- Des tuiles des photos elles-mêmes, utilisable dans iD ou JOSM,



On y voit qu'il pleut à Bordeaux,   
autant qu'en Bretagne (c'est dire)

Superbe boulot, Fred

Merci !

Jacques
--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] takeout Mapillary... déjà 2To et 1.5 million de photos

2020-07-01 Par sujet Frédéric Rodrigo 

Le 01/07/2020 à 18:04, Christian Quest a écrit :

Le 01/07/2020 à 17:42, Georges Dutreix via Talk-fr a écrit :

BonjourChristian,

Simplement pour satisfaire ma curiosité ...
Y-a-t-il une communication sur les différents canaux qu'utilisent les 
contributeurs OSM français ? Francophones ? Avec d'autres "chapitres" 
OSM ?

Est-il judicieux de partager l'url et le message "versez-y vos photos" ?

Le coût de stockage est-il supporté par l'association osm-fr ?

Merci.


Partons de la fin... le coût du stockage est supporté par... moi.

Il s'agit de mon serveur de stockage, dans lequel j'ai rajouté une 
pelleté de disques (9 disques de 3To).


Coût du serveur et des disques: nul (récup de datacenter)

Le principal coût est la facture d'électricité (que j'essaye de 
limiter) et mes abonnements fibres.



Comme ce n'est pas extensible à l'infini, je limite la communication 
ici ;)


Il n'y a pas encore eu de discussion au niveau asso/CA sur le soutien 
à ces démarches de takeout. Ce qui est sûr, c'est que nous n'avons pas 
actuellement la place sur les serveurs de l'asso pour cela. On peut si 
on le décide aligner quelques machines en plus, rajouter des disques 
plus adaptés (on trouve des 8To pour moins de 150 euros en occasion 
pro). J'ai deux Dell R510 avec 12 baies 3.5" qui pourraient chacun 
stocker facilement 80To pour un coût limité.




Pendant ce temps-là sur l'autre instance hébergé par osm-fr, avec peu de 
stockage, je continue à avancer pour rassembler les outils pour utiliser 
ces photo. C'est plus une preuve de faisabilité et beaucoup de scotch 
qu'autre chose.


Il y a donc maintenant :
- La récupération depuis Mapillary (le takeout) 
(https://github.com/frodrigo/mapillary_takeout_web)
- Une carte des photo (de l'instance) 
https://mapillary-takeout-web.openstreetmap.fr/map/
- Des tuiles des photos elles-mêmes, utilisable dans iD ou JOSM, 
https://mapillary-takeout-web.openstreetmap.fr/tms , certains diront que 
c'est innovant, d'autres bizarres et certains déroutants, mais c'est le 
plus simple que j'ai pu trouver sans même avoir besoin de modifier ou 
faire des plugins pour les softs.
- Du floutage des personnes et véhicules, mais ce pas encore déployé. 
https://github.com/tyndare/blur-persons 
https://user-images.githubusercontent.com/1785486/86173942-0e82f600-bb21-11ea-8245-41994b98d505.jpg


Frédéric.


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

Re: [OSM-talk-fr] Noms des quartiers en ville postal_code)

2020-07-01 Par sujet osm . sanspourriel 

J'ai vérifié : il existe une réalisation de ce formatage en PHP, donc si
vous pensez que c'est intéressant un petit +1 sur

https://github.com/osm-search/Nominatim/issues/213#issuecomment-652466541

Je vois une scorie d'une ancienne version anglaise qui est présente sur
la page FR:Key:place  :

postal_code  Text
nœud  chemin
 zone
 Code postal. (Lui
préférer addr:postcode
=*)

Or la pratique en France (sauf par Philippe !) c'est d'utiliser comme
ailleurs dans le monde postal_code
 sur les communes
et et de réserver les addr:* aux adresses.

On met en cohérence avec la pratique ? On vire l'info ?

Jean-Yvon


Le 01/07/2020 à 13:26, Yves P. - yves.prat...@gmail.com a écrit :

C'est un problème de Nominatim qui ne dit pas tout simplement "14,
Chemin des Gravas, 04000 Digne-les-Bains, France"

J'avais demandé il y a quelques années aux développeurs de mettre un
formatage par pays pour éviter ce problème, sans résultat :/


J'ai retrouvé le ticket.
https://github.com/osm-search/Nominatim/issues/213

Il y a un projet qui formate les adresses en fonction des usages dans
les pays : https://github.com/OpenCageData/address-formatting

Je viens d'essayer avec l'API de démo
 du géocodeur OpenCage pour ton adresse
à Digne :
 14 Chemin des Gravas, 04000 Digne-les-Bains, France

Il est aussi mentionné un fichier de config par pays dans iD, mais je
ne sais pas si il est utilisé : iD/data/address-formats.json


Il faudrait peut-être relancer les développeurs de Nominatim pour
intégrer ça ?

__
Yves

___
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] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet osm . sanspourriel 

Le 01/07/2020 à 17:49, Christian Quest - cqu...@openstreetmap.fr a écrit :


Voilà pourquoi on a toujours poussé pour séparer et ne pas mélanger.


Entièrement d'accord sur le raisonnement.

Maintenant si on regarde les règles en France il y a en fait un
qualificatif en plus de l'adresse. "Type de position" selon
adresse.data.gouv.fr mais je n'ai pas trouvé la définition. J'ai trouvé
entrée, inconnu.

Procéder de cette manière permettrait d'avoir plusieurs adresses tout en
sachant à quoi ça correspond.

addr:role=contact par exemple.

*Le gros avantage c'est que c'est compatible avec les éditeurs
existants* (il faut "juste" convaincre d'ajouter un champ, pas de tout
casser pour que les addr: des POI atterrissent dans les contact:addr:*).

Et transformer les contact:addr:* en addr: se ferait sans perte.

C'est sans doute plus facile que d'imposer un schéma de facto
franco-français.

En rêvant tout haut :
contact;entrance;mailbox;registry;water;electricity;gas;FTTH;plaque;entrance.

Registry : l'adresse là où la met le cadastre, le SIG de la ville, unicité

Mailbox : là où se trouve la boîte-aux-lettres pour distribuer le
courrier à cette adresse (peut être loin dans le cas des CIDEX
), unicité

Contact : tous les POI ayant cette adresse ont au moins
addr:role=contact mais ça peut aussi être addr:role=contact;registry.
Pas nécessairement unique.

Plaque : là ou se trouve la plaque de rue, unicité. Pas nécessairement
unique.

Entrance : l'endroit par lequel on arrive à cette adresse. Pas
nécessairement unique.

J'ajoute volontairement water;electricity;gas;FTTH pour provoquer des
réactions : là où se trouvent les différents compteurs (eau,
électricité, gaz) ou entrées (FTTH). Pour l'électricité c'est peut-être
plutôt l'endroit d'entrée dans la place.

En effet, j'ai vu le concessionnaire de l'eau potable relever les
positions géographiques des compteurs. Actuellement ces relevés il les
garde pour lui. Je me dis comme François que préparer le terrain ne peut
nuire ;-).

Christian R., non, adresse n'implique pas bâti. On a déjà évoqué sur la
liste le cas des lotissements où les nom de rue et les numéros sont
fixées avant la construction. Il y a aussi des cas limites intéressants
comme cette adresse de bateau-restaurant détruit
.

Pour compléter le tableau, si certaines fois Nominatim se plante sur les
lieux-dits bornés c'est que Nominatim ne se sert pas des adresses mais
des rues
.

Question subsidiaire : quelle(s) adresses à mettre dans associatedStreet
? Toutes ? Que celles registry et/ou plaque ?

Jean-Yvon

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Yves P. 
> Si il n'y a pas de addr:xxx déjà présent, il faudrait l'ajouter à sa place et 
> pas comme un effet de bord de tel ou tel import de POI.
Ou prendre le temps de créer le point adresse et ne pas rajouter de contact:* 

Je vois l'intérêt de contact:* quand l'adresse postale est différente du n° de 
rue le plus proche.

__
Yves

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

Re: [OSM-talk-fr] takeout Mapillary... déjà 2To et 1.5 million de photos

2020-07-01 Par sujet Christian Quest 

Le 01/07/2020 à 17:42, Georges Dutreix via Talk-fr a écrit :

BonjourChristian,

Simplement pour satisfaire ma curiosité ...
Y-a-t-il une communication sur les différents canaux qu'utilisent les 
contributeurs OSM français ? Francophones ? Avec d'autres "chapitres" 
OSM ?

Est-il judicieux de partager l'url et le message "versez-y vos photos" ?

Le coût de stockage est-il supporté par l'association osm-fr ?

Merci.


Partons de la fin... le coût du stockage est supporté par... moi.

Il s'agit de mon serveur de stockage, dans lequel j'ai rajouté une 
pelleté de disques (9 disques de 3To).


Coût du serveur et des disques: nul (récup de datacenter)

Le principal coût est la facture d'électricité (que j'essaye de limiter) 
et mes abonnements fibres.



Comme ce n'est pas extensible à l'infini, je limite la communication ici ;)

Il n'y a pas encore eu de discussion au niveau asso/CA sur le soutien à 
ces démarches de takeout. Ce qui est sûr, c'est que nous n'avons pas 
actuellement la place sur les serveurs de l'asso pour cela. On peut si 
on le décide aligner quelques machines en plus, rajouter des disques 
plus adaptés (on trouve des 8To pour moins de 150 euros en occasion 
pro). J'ai deux Dell R510 avec 12 baies 3.5" qui pourraient chacun 
stocker facilement 80To pour un coût limité.


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Christian Quest 

Le 30/06/2020 à 23:18, Florian LAINEZ a écrit :
@jérome @jean-yvon @Yves je suis très conscient des effets de bords 
que vous mentionnez et je suis embêté.
A vrai dire je suis à deux doigts de suggérer d'abandonner totalement 
ces "contact:" à tout jamais.


Je constate en effet que 9500 contact:street sont en France sur les 
10300 utilisés de par le Monde, soit 92%. Autant dire que c'est un tag 
franco-français.


Cela me fait réfléchir sérieusement : @christian @vdct pourriez-vous 
svp rappeler les raisons qui nous ont poussé à utiliser ces tags ?
Y a-t-il d'autres raisons que celle, évidente, d'éviter les doublons 
d'adresse ? Est-ce que cela justifie vraiment de créer tout un jeu de 
tags qui n'est utilisé que par les français et qui restera durablement 
incompatible avec les outils d'édition prédominants ?


Ces tags n'apparaissent pas sur les pages
https://wiki.openstreetmap.org/wiki/FR:Adresses
https://wiki.openstreetmap.org/wiki/FR:Key:contact
Par ailleurs le graphique en haut de la page 
https://wiki.openstreetmap.org/wiki/Key:contact indique la popularité 
déclinante des tags "contact:" ces dernières années.


Désolé de ressortir ce vieux squelette du placard mais je ne m'étais 
pas rendu compte que la France faisait exception sur le sujet et j'ai 
l'impression qu'on a fait fausse route depuis des années.

Ne serait-il pas temps de tuer le monstre ?

Florian, qui donne entre 2 mails un avis totalement opposé (après 
avoir creusé le sujet)



Les adresses... un sujet sans fin ;)

Comment différencier la définition d'une adresse (sa localisation, son 
rattachement à une voie, etc) et l'adresse à laquelle se trouve un POI 
qui n'est pas "lui même" l'adresse ?


Si on utilise le même tag pour les deux, faire la différence devient 
complexe voire impossible.


addr:xxx est bien adapté à définir l'adresse, sa position, et ce tag 
devrait normalement être présent une seule fois dans les données OSM 
pour chaque adresse.


contact:xxx indique plein d'infos liées au POI, et son adresse peut en 
être une, on peut avoir plusieurs POI à la même adresse, etc.


Voilà pourquoi on a toujours poussé pour séparer et ne pas mélanger.

https://wiki.openstreetmap.org/wiki/Key:contact indique bien que 
contact:xxx sert à indiquer le numéro, la rue, le code postal et la 
ville où se trouve le POI.


Aucune idée du manque d'adoption ailleurs qu'en France. Peut-être est-ce 
parce qu'on s'est intéressé plus en détail sur le sujet des adresses 
avec BANO ?



C'est bien souvent lors d'imports qu'on se retrouve avec une adresse 
dans les données d'origine et qu'on veut la conserver dans OSM.


Si il n'y a pas de addr:xxx déjà présent, il faudrait l'ajouter à sa 
place et pas comme un effet de bord de tel ou tel import de POI. 
D'ailleurs, en laissant contact:xxx sur le POI, une analyse osmose 
pourrait être faite pour détecter les contact:xxx existants sans 
addr:xxx correspondants... si elle n'existe pas déjà !



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] takeout Mapillary... déjà 2To et 1.5 million de photos

2020-07-01 Par sujet Georges Dutreix via Talk-fr 

BonjourChristian,

Simplement pour satisfaire ma curiosité ...
Y-a-t-il une communication sur les différents canaux qu'utilisent les 
contributeurs OSM français ? Francophones ? Avec d'autres "chapitres" OSM ?

Est-il judicieux de partager l'url et le message "versez-y vos photos" ?

Le coût de stockage est-il supporté par l'association osm-fr ?

Merci.


Le 01/07/2020 à 17:30, Christian Quest a écrit :
Sur le petit service https://takeitout.cquest.org il y a déjà plus de 
1.5 million de photos récupérées de Mapillary pour un volume dépassant 
2To.


N'hésitez pas à renseigner les infos pour votre compte, il reste plus 
de 15To de libre ;)




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

[OSM-talk-fr] takeout Mapillary... déjà 2To et 1.5 million de photos

2020-07-01 Par sujet Christian Quest 
Sur le petit service https://takeitout.cquest.org il y a déjà plus de 
1.5 million de photos récupérées de Mapillary pour un volume dépassant 2To.


N'hésitez pas à renseigner les infos pour votre compte, il reste plus de 
15To de libre ;)


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-07-01 Par sujet Philippe Verdy 
En revanche "boundary=urban" serait approprié pour le zonage urbain
statistique de l'Insee: aires urbaines, pôle urbains...
Mais là ces zones sont composées de zones administratives: communes
entières ou divisions infracommunales officielles, et pour les plus petites
zones les IRIS...
Voire les "TRIRIS", quand les IRIS sont trop privés car les IRIS sont typés
résidentiel/commercial... le TRIRIS corrige cet effet en devenant neutre et
respectant les contraintes du secret statistique obligatoire et les
obligations issues de la loi Informatique et libertés et les
recommandations de la CNIL (un TRIRIS est un assemblage de souvent 3 IRIS,
d'où leur nom, et tous les IRIS n'ont pas besoin d'être ainsi regroupés et
ils ne le sont pas tous, le TRIRIS est un substitut aux IRIS quand les
données détaillées par IRIS typé ne peuvent pas être légalement publiées:
données fiscales par exemple)


Le mer. 1 juil. 2020 à 16:57, Philippe Verdy  a écrit :

> En fait le choix du tag "boundary=urban" me semble pas approprié.
>
> Ce devrait être "boundary=restriction" avec les tags habituels des
> restrictions (maxspeed=*) et éventuellement un tag franco-français
> indiquant le type de limite.
>
> Ce genre de relation pourrait avoir comme membre les noeuds des panneaux
> indicateurs, comme prérequis indispensable, le polygone lui-même avec le
> rôle "outer" (ou l'ensembles des ways dont des "outer" et d'éventuels
> "inner" étant optionnel).
>
> Dans la plupart des cas, les polygones sont "flous", sauf pour les
> communes entièrement urbaines ayant décidé d'appliquer ces limites à la
> totalité de leur territoire adminiqtratif (dans ce cas pas besoin de ces
> relations).
>
>
> Le mer. 1 juil. 2020 à 16:51, Philippe Verdy  a écrit :
>
>> Ces boundary=urban ont été tracés effectivement approcimativement mais
>> visiblement uniquement pour gérer les restrictions de limite de vitesse en
>> agglomération et fournir des "règles" par défaut pour toutes les voies
>> incluses sans avoir à renseigner sur chaque voie les limites effectives. Je
>> pense que le principe est juste de d'appuyer sur les points  marqués par
>> les panneaux d'entrée en agglomération, et les relier entre eux en un
>> polygone fermé, car les points des panneaux seuls ne suffisent pas.
>>
>> Ces polygones n'indiquent en aucun cas un objet physique, une limite
>> administrative réelle, un réel zonage urbain (au sens de l'Insee), c'est
>> juste un complément pour les restrictions du code de la route applicable
>> aux véhicules motorisés. Leur seul intérêt c'est qu'ils délimitent les
>> zones où les tags de limitation de vitesse sont à renseigner (leur source
>> devrait indiquer la règle "urban") ou remettre à jour. Ce sont des objets
>> de "construction" et de 'maintenance" plus que des objets réels. Ils ne
>> remplacent pas le besoin de marquer et détailler les limites de vitesse
>> voie par voie. Mais ils peuvent servent pour détecter les oublis ou
>> incohérences.
>>
>> Cependant je pense que leur place serait plutôt dans une base
>> cartographique séparée (cartosm ?) qu'on peut charger sélectivement. Ce
>> serait d'ailleurs intéressant de mettre en place cette base centralisée
>> externe pour gérer ça, et ensuite pouvoir mettre à jour ou maintenir les
>> vitesses des voies dans OSM (avec un tag mentionnant l'origine et la raison
>> de la vitesse indiquée : un aspect réglementaire en France lié aux panneaux
>> d'entrée en aglolomération). Cette base est assez facile à construire et
>> maintenir, et devrait ensuite permettre de faire des recherches croisées
>> dans OSM en s'appuyant sur les polygones simples fournis par cette base
>> pour chercher dans OSM les voies incohérentes ou non renseignées. Cela peut
>> grandement faciliter la maintenance (y compris les évolutions locales quand
>> les panneaux d'entrée d'agglomération sont déplacés).
>>
>> Cette base externe pourrait aussi gérer des zones plus réglementées
>> (zones 30, zones mixtes prioritaires aux piétons). Elle pourrait servir à
>> d'autres zonages réglementaires (pollution...)
>>
>>
>> Le mer. 1 juil. 2020 à 15:27, Pierre-Yves Mevel via Talk-fr <
>> talk-fr@openstreetmap.org> a écrit :
>>
>>> Bonjour,
>>>
>>> Pour information, j'ai eu la désagréable surprise de voir ressurgir ces
>>> abominations que nous avions patiemment supprimées au cours de ces derniers
>>> mois du territoire de l'Ille-et-Vilaine (cf. ce changeset :
>>> https://www.openstreetmap.org/changeset/87258927?way_page=3 par
>>> exemple). La méthode est toujours la même que celle pointée par Christian R
>>> il y a un an et demi : tracé approximatif (il passe allègrement à travers
>>> des quartiers d'habitation, voire des maisons), chevauchement de ses
>>> polygones, absence de fondement administratif alors qu'il les range dans un
>>> "admin_level", pas de concertation avec les locaux.
>>> À cette liste, il faut ajouter que des appli comme OSMand fait
>>> apparaître ces limites avec la même symbologie que les vraies limites
>>> communales, ce

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-07-01 Par sujet Vincent Bergeot 

Le 01/07/2020 à 15:27, Pierre-Yves Mevel via Talk-fr a écrit :

Bonjour,

Pour information, j'ai eu la désagréable surprise de voir ressurgir 
ces abominations que nous avions patiemment supprimées au cours de ces 
derniers mois du territoire de l'Ille-et-Vilaine (cf. ce changeset : 
https://www.openstreetmap.org/changeset/87258927?way_page=3 par 
exemple). La méthode est toujours la même que celle pointée par 
Christian R il y a un an et demi : tracé approximatif (il passe 
allègrement à travers des quartiers d'habitation, voire des maisons), 
chevauchement de ses polygones, absence de fondement administratif 
alors qu'il les range dans un "admin_level", pas de concertation avec 
les locaux.
À cette liste, il faut ajouter que des appli comme OSMand fait 
apparaître ces limites avec la même symbologie que les vraies limites 
communales, ce qui rend la carte particulièrement illisible dans 
certains cas.


Pour ma part, je dégage à vue sur le territoire de mon EPCI, mais il 
faudrait sans doute trouver une solution plus efficace pour traiter ce 
problème.


Bonjour,

pour imaginer faire des choses il faut déjà le signaler à l'auteur. 
Peux-tu faire un commentaire sur sa modification en expliquant ce qui ne 
te convient pas (à peu de choses près, c'est un copié collé de ton mail) ?


et voir les retours !

bonne journée










Bonne journée,

P-Y

Le ven. 16 nov. 2018 à 10:21, Christian Rogel 
> a écrit :


> Le 16 nov. 2018 à 07:59, Stéphane Péneau
mailto:stephane.pen...@wanadoo.fr>> a
écrit :
> Il en a été question ici même, en aout 2016 :
>
https://lists.openstreetmap.org/pipermail/talk-fr/2016-August/081842.html

Bien que lecteur assidu de la liste, je n’avais pas remarqué ce post.
Il n’empêche que la page a été créée bien avant la tentative de
discussion/demande d’aide.
La justification par les besoins de l’aviation est admissible,
mais le choix d’une réalisation “sauvage” beaucoup moins.
On ne voit pas le bénéfice de troquer la facilité de se référer
aux limites officielles des parcelles bâties pour une exécution
approximative basée sur un nombre d’accroche limité.

Christian R.

___
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



--
Vincent Bergeot

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

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-07-01 Par sujet Philippe Verdy 
En fait le choix du tag "boundary=urban" me semble pas approprié.

Ce devrait être "boundary=restriction" avec les tags habituels des
restrictions (maxspeed=*) et éventuellement un tag franco-français
indiquant le type de limite.

Ce genre de relation pourrait avoir comme membre les noeuds des panneaux
indicateurs, comme prérequis indispensable, le polygone lui-même avec le
rôle "outer" (ou l'ensembles des ways dont des "outer" et d'éventuels
"inner" étant optionnel).

Dans la plupart des cas, les polygones sont "flous", sauf pour les communes
entièrement urbaines ayant décidé d'appliquer ces limites à la totalité de
leur territoire adminiqtratif (dans ce cas pas besoin de ces relations).


Le mer. 1 juil. 2020 à 16:51, Philippe Verdy  a écrit :

> Ces boundary=urban ont été tracés effectivement approcimativement mais
> visiblement uniquement pour gérer les restrictions de limite de vitesse en
> agglomération et fournir des "règles" par défaut pour toutes les voies
> incluses sans avoir à renseigner sur chaque voie les limites effectives. Je
> pense que le principe est juste de d'appuyer sur les points  marqués par
> les panneaux d'entrée en agglomération, et les relier entre eux en un
> polygone fermé, car les points des panneaux seuls ne suffisent pas.
>
> Ces polygones n'indiquent en aucun cas un objet physique, une limite
> administrative réelle, un réel zonage urbain (au sens de l'Insee), c'est
> juste un complément pour les restrictions du code de la route applicable
> aux véhicules motorisés. Leur seul intérêt c'est qu'ils délimitent les
> zones où les tags de limitation de vitesse sont à renseigner (leur source
> devrait indiquer la règle "urban") ou remettre à jour. Ce sont des objets
> de "construction" et de 'maintenance" plus que des objets réels. Ils ne
> remplacent pas le besoin de marquer et détailler les limites de vitesse
> voie par voie. Mais ils peuvent servent pour détecter les oublis ou
> incohérences.
>
> Cependant je pense que leur place serait plutôt dans une base
> cartographique séparée (cartosm ?) qu'on peut charger sélectivement. Ce
> serait d'ailleurs intéressant de mettre en place cette base centralisée
> externe pour gérer ça, et ensuite pouvoir mettre à jour ou maintenir les
> vitesses des voies dans OSM (avec un tag mentionnant l'origine et la raison
> de la vitesse indiquée : un aspect réglementaire en France lié aux panneaux
> d'entrée en aglolomération). Cette base est assez facile à construire et
> maintenir, et devrait ensuite permettre de faire des recherches croisées
> dans OSM en s'appuyant sur les polygones simples fournis par cette base
> pour chercher dans OSM les voies incohérentes ou non renseignées. Cela peut
> grandement faciliter la maintenance (y compris les évolutions locales quand
> les panneaux d'entrée d'agglomération sont déplacés).
>
> Cette base externe pourrait aussi gérer des zones plus réglementées (zones
> 30, zones mixtes prioritaires aux piétons). Elle pourrait servir à d'autres
> zonages réglementaires (pollution...)
>
>
> Le mer. 1 juil. 2020 à 15:27, Pierre-Yves Mevel via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Bonjour,
>>
>> Pour information, j'ai eu la désagréable surprise de voir ressurgir ces
>> abominations que nous avions patiemment supprimées au cours de ces derniers
>> mois du territoire de l'Ille-et-Vilaine (cf. ce changeset :
>> https://www.openstreetmap.org/changeset/87258927?way_page=3 par
>> exemple). La méthode est toujours la même que celle pointée par Christian R
>> il y a un an et demi : tracé approximatif (il passe allègrement à travers
>> des quartiers d'habitation, voire des maisons), chevauchement de ses
>> polygones, absence de fondement administratif alors qu'il les range dans un
>> "admin_level", pas de concertation avec les locaux.
>> À cette liste, il faut ajouter que des appli comme OSMand fait apparaître
>> ces limites avec la même symbologie que les vraies limites communales, ce
>> qui rend la carte particulièrement illisible dans certains cas.
>>
>> Pour ma part, je dégage à vue sur le territoire de mon EPCI, mais il
>> faudrait sans doute trouver une solution plus efficace pour traiter ce
>> problème.
>>
>> Bonne journée,
>>
>> P-Y
>>
>> Le ven. 16 nov. 2018 à 10:21, Christian Rogel <
>> christian.ro...@club-internet.fr> a écrit :
>>
>>> > Le 16 nov. 2018 à 07:59, Stéphane Péneau 
>>> a écrit :
>>> > Il en a été question ici même, en aout 2016 :
>>> >
>>> https://lists.openstreetmap.org/pipermail/talk-fr/2016-August/081842.html
>>>
>>> Bien que lecteur assidu de la liste, je n’avais pas remarqué ce post.
>>> Il n’empêche que la page a été créée bien avant la tentative de
>>> discussion/demande d’aide.
>>> La justification par les besoins de l’aviation est admissible, mais le
>>> choix d’une réalisation “sauvage” beaucoup moins.
>>> On ne voit pas le bénéfice de troquer la facilité de se référer aux
>>> limites officielles des parcelles bâties pour une exécution approximative
>>> basée sur un

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-07-01 Par sujet Philippe Verdy 
Ces boundary=urban ont été tracés effectivement approcimativement mais
visiblement uniquement pour gérer les restrictions de limite de vitesse en
agglomération et fournir des "règles" par défaut pour toutes les voies
incluses sans avoir à renseigner sur chaque voie les limites effectives. Je
pense que le principe est juste de d'appuyer sur les points  marqués par
les panneaux d'entrée en agglomération, et les relier entre eux en un
polygone fermé, car les points des panneaux seuls ne suffisent pas.

Ces polygones n'indiquent en aucun cas un objet physique, une limite
administrative réelle, un réel zonage urbain (au sens de l'Insee), c'est
juste un complément pour les restrictions du code de la route applicable
aux véhicules motorisés. Leur seul intérêt c'est qu'ils délimitent les
zones où les tags de limitation de vitesse sont à renseigner (leur source
devrait indiquer la règle "urban") ou remettre à jour. Ce sont des objets
de "construction" et de 'maintenance" plus que des objets réels. Ils ne
remplacent pas le besoin de marquer et détailler les limites de vitesse
voie par voie. Mais ils peuvent servent pour détecter les oublis ou
incohérences.

Cependant je pense que leur place serait plutôt dans une base
cartographique séparée (cartosm ?) qu'on peut charger sélectivement. Ce
serait d'ailleurs intéressant de mettre en place cette base centralisée
externe pour gérer ça, et ensuite pouvoir mettre à jour ou maintenir les
vitesses des voies dans OSM (avec un tag mentionnant l'origine et la raison
de la vitesse indiquée : un aspect réglementaire en France lié aux panneaux
d'entrée en aglolomération). Cette base est assez facile à construire et
maintenir, et devrait ensuite permettre de faire des recherches croisées
dans OSM en s'appuyant sur les polygones simples fournis par cette base
pour chercher dans OSM les voies incohérentes ou non renseignées. Cela peut
grandement faciliter la maintenance (y compris les évolutions locales quand
les panneaux d'entrée d'agglomération sont déplacés).

Cette base externe pourrait aussi gérer des zones plus réglementées (zones
30, zones mixtes prioritaires aux piétons). Elle pourrait servir à d'autres
zonages réglementaires (pollution...)


Le mer. 1 juil. 2020 à 15:27, Pierre-Yves Mevel via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> Pour information, j'ai eu la désagréable surprise de voir ressurgir ces
> abominations que nous avions patiemment supprimées au cours de ces derniers
> mois du territoire de l'Ille-et-Vilaine (cf. ce changeset :
> https://www.openstreetmap.org/changeset/87258927?way_page=3 par exemple).
> La méthode est toujours la même que celle pointée par Christian R il y a un
> an et demi : tracé approximatif (il passe allègrement à travers des
> quartiers d'habitation, voire des maisons), chevauchement de ses polygones,
> absence de fondement administratif alors qu'il les range dans un
> "admin_level", pas de concertation avec les locaux.
> À cette liste, il faut ajouter que des appli comme OSMand fait apparaître
> ces limites avec la même symbologie que les vraies limites communales, ce
> qui rend la carte particulièrement illisible dans certains cas.
>
> Pour ma part, je dégage à vue sur le territoire de mon EPCI, mais il
> faudrait sans doute trouver une solution plus efficace pour traiter ce
> problème.
>
> Bonne journée,
>
> P-Y
>
> Le ven. 16 nov. 2018 à 10:21, Christian Rogel <
> christian.ro...@club-internet.fr> a écrit :
>
>> > Le 16 nov. 2018 à 07:59, Stéphane Péneau 
>> a écrit :
>> > Il en a été question ici même, en aout 2016 :
>> >
>> https://lists.openstreetmap.org/pipermail/talk-fr/2016-August/081842.html
>>
>> Bien que lecteur assidu de la liste, je n’avais pas remarqué ce post.
>> Il n’empêche que la page a été créée bien avant la tentative de
>> discussion/demande d’aide.
>> La justification par les besoins de l’aviation est admissible, mais le
>> choix d’une réalisation “sauvage” beaucoup moins.
>> On ne voit pas le bénéfice de troquer la facilité de se référer aux
>> limites officielles des parcelles bâties pour une exécution approximative
>> basée sur un nombre d’accroche limité.
>>
>> Christian R.
>>
>> ___
>> 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] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Philippe Verdy 
A mon avis si l'adresse de contact est la même que l'adresse de situation
du commerce/service, il ne faut pas la renseigner. Le but est plutôt de
renseigner une adresse postale d'un service externalisé (ou centralisé
ailleurs, au siège d'une organisation multi-site, quand le "brand" ne
suffit pas car cela concerne des franchises qui légalement sont séparées,
la maison-mère de la franchise ne s'occupant pas de tout), ou une boite
postale poste restante.

Cependant dans divers cas, une seule adresse de contact ne suffit pas:
commerces multifranchises, avec différentes adresses selon le service vendu
ou si on désigne l'adresse du gérant des lieux ou l'adresse légale de
l'entité locale (celle enregistrée au registre du commerce et figurant sur
les factures/devis/tickets de caisse avec son propre nom, pas affiché du
tout sur place : nombre de cafés, restaurants, tabacs ont une désignation
légale du gérant avec son nom et son adresse privée qui n'a rien à voir
avec l'adresse physique du commerce ou celle des sièges des franchises
auquel il a adhéré ; c'est le cas même pour des chaînes très connues comme
McDonald ou Quick, ou les stations-services comme Leclerc, et la quasi
totalité des supermarchés et hypers de Carrefour, Leclerc, Géant/Casino,
Lidl, But, Conforama, etc.). Concernant les drives et autres points de
retraits l'adresse de contact (légal ou service consommateur) n'est
quasiment jamais sur place.

Même les services publics ont d'autres adresses de contact que celle de
l'agence locale (y compris les services municipaux dont l'adresse de
contact est un service interne à la mairie, ou celle de la mairie
elle-même, et non celle du local lui-même; de même les services fiscaux, et
même aujourd'hui les services postaux, qui sont sectorisés selon le mode de
distribution et le service : pour les retraits et livraisons de colis c'est
déjà séparé du bureau de poste local).

Bref "contact:*" c'est bien mais même pas suffisant si on en veut plusieurs
selon le service. En revanche "addr:*" est à bannir sur les POI (sauf si le
numéro est ambigu et pas facile à déterminer géographiquement parmi les
points d'adresse proches, auquel cas on peut avoir juste addr:housenumber
qui peut inclure un intervalle de numéro, et éventuellement addr:street
pour indiquer par laquelle des voies proches on accède principalement) et
ne devrait plus servir que sur les noeuds d'adresse anonymes.

Dans certains cas, un commerce a plusieurs points d'accès publics sur des
rues différentes, et il peut être justifié d'avoir plusieurs jeux de tags
"addr:". Mais indiquer la commune est redondant sauf si l'accès est sur une
commune voisine ou si le bâtiment est à cheval sur plusieurs communes et a
plusieurs accès (le commerce ou service peut élire domicile dans une
d'elles ce n'est pas déterminé facilement par la géométrie ou même par le
positionnement du noeud POI arbitrairement sur une des communes ou un de
ses accès, et il n'est pas question non plus de mettre plusieurs noeuds POI
quand c'est un seul et même service)

Pour les points d'accès, je pense qu'il on n'a pas besoin de leur donner
une adresse ou les attribuer à un noeud POI proche, c'est plutôt une
caractéristique physique et l'interconnexion entre eux est sur un domaine
privé: les champs "addr:*" du POI suffisent à déterminer l'adresse ou les
adresses d'accès, les noeuds des points d'accès (entry) sont à taguer
physiquement sur les bâtiments/clôtures, et complétés éventuellement par
des voies privées (highway=* + access=*) y compris internes au
bâtiment (exemple: galeries marchandes pour relier les commerces "indoor",
voire souterrains dans les tunnels des gares ferroviaires et stations
métro).

D'une façon générale, ne pas faire de règle préétablie interdisant ou
obligeant à utiliser certains tags : la géographie a besoin de
nombreuses exceptions aux règles. Mais ces exceptions doivent être
justifiées par un besoin et ne pas devenir une règle introduisant beaucoup
de redondance totalement inutile, ou empêchant d'indiquer une précision
nécessaire non couverte correctement par les règles géographique de
"proximité" ou d'inclusion dans une aire administrative).

Les adresses postales sont connues pour justement échapper aux règles de
divisions administratives (et pas seulement pour les codes postaux) pour
ceux qui habitent dans des zones frontalières desservies et accessibles
uniquement par une autre commune (en pratique, en excluant les autres accès
privés, par de petits chemins piétons ou privés à travers les jardins, ou
les voies de garage ou parking strictement privé, ou via un droit de
passage par une autre propriété réservé aux occupants et aux services
publics autorisés).

Le mar. 30 juin 2020 à 23:19, Florian LAINEZ  a écrit :

> @jérome @jean-yvon @Yves je suis très conscient des effets de bords que
> vous mentionnez et je suis embêté.
> A vrai dire je suis à deux doigts de suggérer d'abandonner totalement ces
> "contact:" à tout jamais.
>
> Je constate en effet que 9500

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-07-01 Par sujet Pierre-Yves Mevel via Talk-fr 
Bonjour,

Pour information, j'ai eu la désagréable surprise de voir ressurgir ces
abominations que nous avions patiemment supprimées au cours de ces derniers
mois du territoire de l'Ille-et-Vilaine (cf. ce changeset :
https://www.openstreetmap.org/changeset/87258927?way_page=3 par exemple).
La méthode est toujours la même que celle pointée par Christian R il y a un
an et demi : tracé approximatif (il passe allègrement à travers des
quartiers d'habitation, voire des maisons), chevauchement de ses polygones,
absence de fondement administratif alors qu'il les range dans un
"admin_level", pas de concertation avec les locaux.
À cette liste, il faut ajouter que des appli comme OSMand fait apparaître
ces limites avec la même symbologie que les vraies limites communales, ce
qui rend la carte particulièrement illisible dans certains cas.

Pour ma part, je dégage à vue sur le territoire de mon EPCI, mais il
faudrait sans doute trouver une solution plus efficace pour traiter ce
problème.

Bonne journée,

P-Y

Le ven. 16 nov. 2018 à 10:21, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

> > Le 16 nov. 2018 à 07:59, Stéphane Péneau  a
> écrit :
> > Il en a été question ici même, en aout 2016 :
> >
> https://lists.openstreetmap.org/pipermail/talk-fr/2016-August/081842.html
>
> Bien que lecteur assidu de la liste, je n’avais pas remarqué ce post.
> Il n’empêche que la page a été créée bien avant la tentative de
> discussion/demande d’aide.
> La justification par les besoins de l’aviation est admissible, mais le
> choix d’une réalisation “sauvage” beaucoup moins.
> On ne voit pas le bénéfice de troquer la facilité de se référer aux
> limites officielles des parcelles bâties pour une exécution approximative
> basée sur un nombre d’accroche limité.
>
> Christian R.
>
> ___
> 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] Noms des quartiers en ville

2020-07-01 Par sujet Arnaud Champollion 

Le 01/07/2020 à 13:59, Yves P. a écrit :

Moi je vois plutôt :

         +-> hameau
  |
commune +
  |
         +-> quartier



OK en effet je reconnais que j'ai été influencé par la hiérarchie faite 
par Nominatim.


Un hameau peut aussi avoir des quartiers, ex :

https://www.openstreetmap.org/node/7252566049#map=17/44.87224/6.03056

Comme les hameaux sont marqués en tant que nodes, j'ai l'impression 
que leur influence s'étend sur tout le centre-ville ou toute autre 
zone qui n'est pas sous l'influence d'un autre hameau.



ça c'est plutôt un "bug" dans Nominatim ?


Je comprends.

Bon, sur Digne ce qu'on peut faire en attendant la résolution du "bug", 
c'est déjà de faire correctement :


--> mettre neigbourhood au lieu de hamlet quand il y a continuité urbaine
--> ajouter les neigbourhood manquants (noms des différents quartiers)

Ça me ramène à une autre discussion plus ancienne. À Digne nous avons un 
certain nombre de quartiers qui sont mappés en tant que 
landuse=residential + name= , bien qu'étant déjà à l'intérieur de 
landuse=residential englobants. Si j'ajoute les neigbourhood, peut-être 
devrais-je supprimer ces landuse ?




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

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-07-01 Par sujet Arnaud Champollion 

Le 01/07/2020 à 13:26, Yves P. a écrit :
Il y a un projet qui formate les adresses en fonction des usages dans 
les pays : https://github.com/OpenCageData/address-formatting


Je viens d'essayer avec l'API de démo  du 
géocodeur OpenCage pour ton adresse à Digne :

 14 Chemin des Gravas, 04000 Digne-les-Bains, France


En effet j'ai testé avec une autre adresse : 44.0877, 6.24994

Cela donne une adresse satisfaisante :

26 Avenue des Thermes, 04000 Digne-les-Bains, France

Alors que Nominatim sur Osmand ou openstreetmap.org donnent une 
indication erronée :


Avenue des Thermes, Les Hautes Sièyes, Digne-les-Bains, 
Alpes-de-Haute-Provence, Provence-Alpes-Côte d'Azur, France 
métropolitaine, 04000, France


En effet, c'est le hameau des Hautes Sièyes, pourtant éloigné, qui étend 
son influence sur toute la ville désormais :)



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

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-07-01 Par sujet Yves P. 
> Il peut y avoir des villages, des hameaux et pourtant une ou des zones 
> urbaines avec des quartiers. On ne met pas de hamlet (ou pire des 
> isolated_dwelling comme signalé à Dignes) dans la zone urbaine.
> 
> C'est juste du bon sens.
> 
Oui c'est bien ça.

J'avais mal compris le cas de figure pensant que c'était des hameaux (faisant 
forcément partie d'une commune).
Exemple dans le Jura : Auge 


En cliquant sur where am I 
 (je 
viens de remarquer ce lien dans l'interface web d'OSM) ça donne la réponse :
Thoiria, Lons-le-Saunier, Jura, Bourgogne-Franche-Comté, France métropolitaine, 
39130, France 

Et avec l'API d'OpenCage :
39130 Barésia-sur-l'Ain, France
46.5323969, 5.7124287
_category: place
_type: village

Auge est bien un hameau, mais de quelle commune ?
Si on regarde le polygone de Thoiria 
, Auge 
n'en fait pas partie !
Bizarrement je ne trouve pas le polygone de Barésia. Y a-t-il un problème de 
données ici ?

Et cerise sur le gâteau, Barésia et Thoiria font partie de la Communauté de 
Communes du Pays des Lacs .
(Elle doit bientôt fusionner avec d'autres com com pour devenir la communauté 
Terre d'Émeraude )

__
Yves

Doit-on afficher les noms de com com dans le géocodage ?
A part la page FR:ComcomMaker 
 je ne trouve rien dans le 
wiki concernant les "Com com".
Pour info, http://comcommaker.openstreetmap.fr affiche une erreur 502



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

Re: [OSM-talk-fr] SPAM, Re: Noms des quartiers en ville

2020-07-01 Par sujet Arnaud Champollion 

Le 30/06/2020 à 09:40, Yves P. a écrit :

Est-ce parce-que "Le Plan de Gaubert" est le place=hamlet le plus proche ?

Oui

https://overpass-turbo.eu/s/VBm


J'ai passé "Le Plan de Gaubert" en "neigbourhood" ce qui est respectueux 
du terrain car il s'agit bien d'un quartier et non d'un hameau.


Depuis, c'est le hameau des Hautes Sieyes (bien visible sur la requête 
overpass) qui étend son influence sur les adresses de toute une partie 
de la ville, même à l'autre bout.


Les Hautes Sieyes font bien partie de la commune de Digne les Bains, 
mais ça mérite d'être taggué "hameau" car il y a bel et bien une 
discontinuité urbaine, du coup le passer en neigbouhood, en effet, ce 
serait tagguer pour Nominatim donc je ne touche pas.




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

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-07-01 Par sujet Yves P. 
> L'idée c'est aussi de respecter une certaine logique dans la hiérarchie des 
> subdivisions : commune --> hameau --> quartier.
??
Moi je vois plutôt :

+-> hameau
|
commune +
|
+-> quartier
> 
> Comme les hameaux sont marqués en tant que nodes, j'ai l'impression que leur 
> influence s'étend sur tout le centre-ville ou toute autre zone qui n'est pas 
> sous l'influence d'un autre hameau.
ça c'est plutôt un "bug" dans Nominatim ?

Pour cela, l'utilisation de règles de formatage pour la France éviterais ce 
problème.

__
Yves

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

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-07-01 Par sujet Arnaud Champollion 

Le 01/07/2020 à 12:31, ades a écrit :

Après les tags spécialement adaptés aux calcul d’itinéraires, voici les tags 
adaptés à nominatim ! Que ce soit l’un ou l’autre il me semble qu’il s’agit de 
rendus et que c’est au « moteur » de rendu de faire son boulot, non ?


Il ne me semble pas que ce soit "tagguer pour nominatim". L'idée c'est 
aussi de respecter une certaine logique dans la hiérarchie des 
subdivisions : commune --> hameau --> quartier.


Comme les hameaux sont marqués en tant que nodes, j'ai l'impression que 
leur influence s'étend sur tout le centre-ville ou toute autre zone qui 
n'est pas sous l'influence d'un autre hameau.






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

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-07-01 Par sujet Yves P. 
> C'est un problème de Nominatim qui ne dit pas tout simplement "14, Chemin des 
> Gravas, 04000 Digne-les-Bains, France"
> 
> J'avais demandé il y a quelques années aux développeurs de mettre un 
> formatage par pays pour éviter ce problème, sans résultat :/

J'ai retrouvé le ticket. https://github.com/osm-search/Nominatim/issues/213

Il y a un projet qui formate les adresses en fonction des usages dans les pays 
: https://github.com/OpenCageData/address-formatting

Je viens d'essayer avec l'API de démo  du 
géocodeur OpenCage pour ton adresse à Digne :
 14 Chemin des Gravas, 04000 Digne-les-Bains, France

Il est aussi mentionné un fichier de config par pays dans iD, mais je ne sais 
pas si il est utilisé : iD/data/address-formats.json 


Il faudrait peut-être relancer les développeurs de Nominatim pour intégrer ça ?

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

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-07-01 Par sujet osm . sanspourriel 


Le 01/07/2020 à 12:57, Yves P. - yves.prat...@gmail.com a écrit :

On réserverait "hamlet" à des communes constituées exclusivement de
hameaux, comme par exemple Valjouffrey :

oui

Non

Il peut y avoir des villages, des hameaux et pourtant une ou des zones
urbaines avec des quartiers. On ne met pas de hamlet (ou pire des
isolated_dwelling comme signalé à Dignes) dans la zone urbaine.

C'est juste du bon sens.

Si l'étalement urbain fait qu'un hamlet ou un village se met à toucher
cette zone, ça devient un neighbourhood.

Jean-Yvon

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

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-07-01 Par sujet osm . sanspourriel 

Effectivement on ne tague pas pour tel ou tel outil.

hamlet n'a rien à faire dans la zone urbaine d'une ville, on ne met pas.

> tous les quartiers mêmes excentrés sont à tagguer "neighbourhood

Excentrés mais partie de la zone urbaine agglomérée.

Si c'est discontigu, c'est village, hamlet, isolated_dwelling.

Et si quel ou tel cas ne marche pas on ouvre ou commente pour que Sarah
regarde :

https://github.com/osm-search/Nominatim/issues/1505

Jean-Yvon

Le 01/07/2020 à 12:31, ades - ades.s...@orange.fr a écrit :

Ah bon ?
Je croyais avoir compris que l’on ne ,taggait pas pour le rendu ?
C’est vrai dans tous les cas ? Après les tags spécialement adaptés aux calcul 
d’itinéraires, voici les tags adaptés à nominatim ! Que ce soit l’un ou l’autre 
il me semble qu’il s’agit de rendus et que c’est au « moteur » de rendu de 
faire son boulot, non ?



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

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-07-01 Par sujet Yves P. 

>> tous les quartiers mêmes excentrés sont à tagguer "neighbourhood").
oui

>> 
>> On réserverait "hamlet" à des communes constituées exclusivement de hameaux, 
>> comme par exemple Valjouffrey :
oui

Il me semble que c'est la logique (et donc on ne tag pas pour le rendu).

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

Re: [OSM-talk-fr] Noms des quartiers en ville

2020-07-01 Par sujet ades 
Ah bon ?
Je croyais avoir compris que l’on ne ,taggait pas pour le rendu ?
C’est vrai dans tous les cas ? Après les tags spécialement adaptés aux calcul 
d’itinéraires, voici les tags adaptés à nominatim ! Que ce soit l’un ou l’autre 
il me semble qu’il s’agit de rendus et que c’est au « moteur » de rendu de 
faire son boulot, non ?


> Le 1 juil. 2020 à 12:00, Arnaud Champollion 
>  a écrit :
> 
> Le 30/06/2020 à 10:04, Christian Quest a écrit :
> 
>> Un chemin près d'un hameau se retrouve rattaché même si il n'en fait pas 
>> partie.
> 
> Ça le fait même sur des distances assez longues.
> 
> Exemple ici :
> 
> https://www.openstreetmap.org/search?whereami=1=44.0903%2C6.2453#map=16/44.0903/6.2453
> 
> Une adresse à l'avenue des Thermes se retrouve comme faisant parties des 
> Hautes Sieyes, un hameau (ou quartier?) pourtant excentré  à l'autre bout de 
> la ville.
> 
> Cela donne des adresses un peu cocasses.
> 
>> Très difficile à changer sans revoir l'ensemble de la logique de nominatim 
>> qui doit surtout s'adapter à des densités très variables d'infos dans OSM.
> 
> Mais on peut en revanche adapter notre façon de tagguer selon le modèle 
> urbain local.
> 
> J'ai l'impression que, dès lors qu'une ville possède, dans la base OSM, des 
> hameaux (place=hamlet) cela crée pour Nominatim un zonage jointif, en 
> d'autres termes tout point géographique semble appartenir à un ou un autre 
> hameau, même des rues en plein centre-ville. Et pour cause : le centre-ville 
> n'a pas de "hamlet", et comme c'est un niveau intermédiaire entre 
> "neigbouhood" et "city", Nominatim "attrape" le hameau le plus proche.
> 
> Donc soit on crée un 'hamlet" par quartier (ce qui est faux d'un point de vue 
> sémantique), soit on n'en met pas du tout, et tous les quartiers mêmes 
> excentrés sont à tagguer "neighbourhood").
> 
> On réserverait "hamlet" à des communes constituées exclusivement de hameaux, 
> comme par exemple Valjouffrey :
> https://www.openstreetmap.org/relation/1299601#map=12/44.8841/6.0737
> 
> Qu'en pensez-vous ?
> 
> ___
> 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] Noms des quartiers en ville

2020-07-01 Par sujet Arnaud Champollion 

Le 30/06/2020 à 10:04, Christian Quest a écrit :

Un chemin près d'un hameau se retrouve rattaché même si il n'en fait pas 
partie.


Ça le fait même sur des distances assez longues.

Exemple ici :

https://www.openstreetmap.org/search?whereami=1=44.0903%2C6.2453#map=16/44.0903/6.2453

Une adresse à l'avenue des Thermes se retrouve comme faisant parties des 
Hautes Sieyes, un hameau (ou quartier?) pourtant excentré  à l'autre 
bout de la ville.


Cela donne des adresses un peu cocasses.

Très difficile à changer sans revoir l'ensemble de la logique de 
nominatim qui doit surtout s'adapter à des densités très variables 
d'infos dans OSM.


Mais on peut en revanche adapter notre façon de tagguer selon le modèle 
urbain local.


J'ai l'impression que, dès lors qu'une ville possède, dans la base OSM, 
des hameaux (place=hamlet) cela crée pour Nominatim un zonage jointif, 
en d'autres termes tout point géographique semble appartenir à un ou un 
autre hameau, même des rues en plein centre-ville. Et pour cause : le 
centre-ville n'a pas de "hamlet", et comme c'est un niveau intermédiaire 
entre "neigbouhood" et "city", Nominatim "attrape" le hameau le plus proche.


Donc soit on crée un 'hamlet" par quartier (ce qui est faux d'un point 
de vue sémantique), soit on n'en met pas du tout, et tous les quartiers 
mêmes excentrés sont à tagguer "neighbourhood").


On réserverait "hamlet" à des communes constituées exclusivement de 
hameaux, comme par exemple Valjouffrey :

https://www.openstreetmap.org/relation/1299601#map=12/44.8841/6.0737

Qu'en pensez-vous ?

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Christian Rogel 
B
> Le 1 juil. 2020 à 08:16, Topographe Fou  a écrit :
> Personnellement et même si le raisonnement est fragile j'ai toujours perçu 
> les addr: comme des propriétés d'un objet, le tag "principal" qui fait la 
> nature d'un objet étant amenity ou shop ou building ou office ou...
>> Désolé de ressortir ce vieux squelette du placard mais je ne m'étais pas 
>> rendu compte que la France faisait exception sur le sujet et j'ai 
>> l'impression qu'on a fait fausse route depuis des années.
>> Ne serait-il pas temps de tuer le monstre ?

L’adresse est fondamentalement une propriété de la parcelle habitée ou siège 
d’activité (la mairie ne met, en principe, pas d’adresse à un terrain nu).
Building et shop ont beau être des tags « principaux », ils ne sont pas au même 
niveau, puisque l’existence des activités dépend, in fine, de l’espace et non 
des objets qui s’y trouvent.

De toute façon, une « décision communautaire française » non discutée à 
l’échelon international, ça ne peut pas valoir grand-chose.

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

Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas

2020-07-01 Par sujet Topographe Fou 
  Personnellement et même si le raisonnement est fragile j'ai toujours perçu les addr: comme des propriétés d'un objet, le tag "principal" qui fait la nature d'un objet étant amenity ou shop ou building ou office ou... Ce qui ne m'empêche pas de trouver une pertinence à leur usage sur des noeuds isolés comme la plupart des objets ayant une adresse à ma connaissance car il faut bien localiser les adresses. Avec un tag type amenity=addr là on pourrait gérer une notion d'unicité d'adresse en rentrant de plein pied dans la règle une feature = un objet et sans s'interdire d'avoir la même adresse sur un cinéma. Mais c'est probablement trop tard pour changer. Pour le coup on peut décider de le faire en France sans tout casser/nous isoler (transparent pour les consommateurs de données, les outils de QA sont assez souples, reste le pb des éditeurs).Je comprend l'esprit de la "décision communautaire" en France mais les adresses sont un pilier des données géographiques que l'on ne peut guère gérer à notre guise. Surtout quand les outils ne suivent pas et incitent à remplir addr:xxx  Reste que l'adresse postale/cadastre n'est pas forcément l'adresse de contact...  LeTopographeFou   De: winner...@free.frEnvoyé: 30 juin 2020 11:30 PMÀ: talk-fr@openstreetmap.org; christian.qu...@gmail.com; v...@laposte.netRépondre à: talk-fr@openstreetmap.orgObjet: Re: [OSM-talk-fr] édition en masse sur les adresses des cinémas  Pour en rajouter une couche, quand on voit la progression de la courbe des tags "contact:" liée aux adresses, elle est carrément flat :https://taghistory.raifer.tech/#***/contact:street/&***/contact:housenumber/&***/contact:postcode/&***/addr:street/&***/addr:housenumber/&***/addr:postcode/Le mar. 30 juin 2020 à 23:18, Florian LAINEZ  a écrit :@jérome @jean-yvon @Yves je suis très conscient des effets de bords que vous mentionnez et je suis embêté.A vrai dire je suis à deux doigts de suggérer d'abandonner totalement ces "contact:" à tout jamais.Je constate en effet que 9500 contact:street sont en France sur les 10300 utilisés de par le Monde, soit 92%. Autant dire que c'est un tag franco-français.Cela me fait réfléchir sérieusement : @christian @vdct pourriez-vous svp rappeler les raisons qui nous ont poussé à utiliser ces tags ?Y a-t-il d'autres raisons que celle, évidente, d'éviter les doublons d'adresse ? Est-ce que cela justifie vraiment de créer tout un jeu de tags qui n'est utilisé que par les français et qui restera durablement incompatible avec les outils d'édition prédominants ?Ces tags n'apparaissent pas sur les pages https://wiki.openstreetmap.org/wiki/FR:Adresseshttps://wiki.openstreetmap.org/wiki/FR:Key:contactPar ailleurs le graphique en haut de la page https://wiki.openstreetmap.org/wiki/Key:contact indique la popularité déclinante des tags "contact:" ces dernières années.Désolé de ressortir ce vieux squelette du placard mais je ne m'étais pas rendu compte que la France faisait exception sur le sujet et j'ai l'impression qu'on a fait fausse route depuis des années.Ne serait-il pas temps de tuer le monstre ?Florian, qui donne entre 2 mails un avis totalement opposé (après avoir creusé le sujet)Le mar. 30 juin 2020 à 15:59, Yves P.  a écrit :On en déduira que quelqu'un a vérifié que le cinéma a été transformé en toilettes^^.Ça ressemble plus à un nettoyage partiel.+1Ou trop rapide :D__Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
-- 


	
	
	
	




	
	
	
	

Florian
Lainez@overflorian
-- 


	
	
	
	




	
	
	
	

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