Ca marche aussi... à peu près. Cela dépend de la précision de
area[name="France"]
telle que dans l'instance utilisée: c'est un très grand polygone qui a été
simplifié pour des raisons de performance (il y a quelques débordements aux
frontières, pas sûr qu'il y ait un "buffer" défini autour de largeur
correspondant à la précision de simplification du polygone complet tel que
défini dans OSM) et qui n'est pas non plus synchronisé en permanence (ceci
dit les frontières nationales bougent très peu, hormis quelques menus
changements liés aux conflations de sources différentes et quelques
désaccord frontaliers comme autour du Mont-Blanc avec l'Italie, avec des
recouvrements partiels des revendications, ceci dit ça n'affecte
principalement que des zones naturelles pas tellement concernées par ces
limites de vitesse dans des parcs naturels de toute façon pas accessible ou
interdits aux véhicules usuels, et où les limites de vitesse théoriques ne
peuvent même pas être atteintes en sécurité, ceci dépendant largement des
véhicules, de leur charge, leur capacité de freinage, leur gabarit, leurs
équipements, et sinon les autorisations d'accès)
Ces "areas" peuvent ne pas suffire, c'est juste approprié pour une
recherche simple, mais il faut ensuite tenter de localiser des unités plus
petites (par exemple une limite de commune). Les "areas" ne sont pas
tellemetn fait pour le géocodage précis, ce sont juste des filtres de
sélection pour les recherches. Si on veut un géocodage précis, il y a
d'autres outils plus appropriés ou on doit faire des recherches
complémentaires.
Je pense même que pour les limites de vitesse, puisqu'elles sont de la
compétence préfectorale (même si elles sont issues de décisions
municipales), l'unité de recherche la plus approprié est le département, et
là on a des polygones précuis sans nécessiter de grosses simplifications.
D'ailleurs je me demande pourquoi on n'a pas une API dédiée au géocodage.
Le dim. 6 sept. 2020 à 22:23, Romain MEHUT <romain.me...@mailo.com> a
écrit :
> Bonjour,
>
> Quand j'ai supprimé les polygones boundary=urban, il m'est arrivé de faire
> quelques corrections annexes comme de retirer des tags addr:country,
> addr:city en particulier sur les relations des radars de vitesse.
>
> Un contributeur m'a contacté car il utilise ces tags pour contrôler leur
> présence via la requête suivante :
>
>
> [out:csv(::id,type,enforcement,"addr:country",maxspeed,"addr:city","addr:postcode","addr:street",ref,milestone,name)];
> relation ["addr:country"="FR"] [type=enforcement] [enforcement=maxspeed]
> ({{bbox}});
> out;
>
> Je lui répond qu'OSM étant par nature une base de données géographiques,
> ces tags sont inutiles et que l'on peut remonter ces informations pour
> chaque objet *via* un géocodage. Il me demande alors une requête qui le
> permet sans les tags addr:
>
> J'ai testé ceci :
>
> [out:csv(::id,maxspeed,ref,milestone,name,::lat,::lon)];
> area[name="France"]->.pays;
> relation(area.pays) [type=enforcement] [enforcement=maxspeed];
> node(r:device);
> out;
>
> et suis passé par https://geo.api.gouv.fr/adresse et /reverse/csv/ pour
> retrouver la ville et le code postal.
>
> Vous validez ma méthode et vous êtes d'accord pour retirer les tags addr: ?
>
> Merci.
>
> Romain
> _______________________________________________
> 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
