API OSM maison
publié le , mis à jour⚙️ Ceci est une proposition de changement de code.
Rendez-vous sur sa page Github pour l'osculter.
@etienneJr je teste l'accès direct à la base depuis une route next pour aller chercher les entités OSM, sans gérer pour l'instant la complexité d'Overpass.
Pour ça, je pense en effet qu'Underpass sera utile. Mais j'essaie d'urgence de résoudre la lenteur des pages lieu.
etienneJr
Salut, @laem Ca va être top cette api ! J'ai poussé quelques commits pour :
- faire la conversion du hstore en jsonb directement dans la requête SQL plutôt que dans le js
- chercher les relations dans planet_osm_rels car elle les contient toutes alors que planet_osm_polygon ne contient que celles de type multipolygon
- récupérer les tags dans planet_osm_nodes et planet_osm_ways car ils sont complets (et correspondent exactement à la liste d'OSM) alors que ceux dans _point, _line et _polygon peuvent avoir été filtrés lors de l'import dans la base pour ne garder que les tags pertinents.
- j'ai rajouté l'accès en lecture à readonlyuser sur _nodes car ça manquait
- Les 2 points précédents nécessitent de rajouter des JOIN pour récupérer les géométries dans _point, _line et _polygon. Attention les géométries ne sont pas dispo pour les relations autres que type=multipolygon.
- ajouter une propriété metadata qui contient les infos sur le changeset. On les prend dans les tables _point, _line et _polygon plutôt que dans les tables _nodes, _ways et _rels car elle incluent le nom du user (et pas seulement son ID) ainsi que l'aire des polygon.
- Problème qui reste : en faisant comme ça on n'a pas les metadata des relations non type=multipolygon, il faudrait les lire dans _rels et les réordonner en jsonb, je pourrai le faire après coup.
J'ai testé chez moi sur les différents cas, ça marche bien.
laem
Trop cool. J'ai beaucoup utilisé Aider avec Claude pour lancer ça. Ça permet d'avancer, merci pour toutes ces corrections.
Attention les géométries ne sont pas dispo pour les relations autres que type=multipolygon.
Tu sais si c'est une limitation de la base, ou de la requête SQL côté client ?
J'ai noté aussi que ça ne marche pas pour certaines way, par exemple
http://localhost:8080/api/osm?featureType=way&osmId=25033797qui a ungeometry{}. À l'inverse une way plus complexe comme celle-ci fonctionnehttp://localhost:8080/api/osm?featureType=way&osmId=17035273.À noter qu'il y a déjà des fonctions probablement utiles ici dans app/osmRequest, notamment pour créer les polygones nécessaires pour l'UI. Je vais mettre ça en commun si possible, car il faut garder aussi le repli overpass pour toutes les zones hors France/Europe.
Tu sais si c'est une limitation de la base, ou de la requête SQL côté client ?
c'est à cause de osm2pgsql, il ne calcule la géométrie que sur les éléments conservés lors du filtrage avec le fichier .style (même sans style perso, il y a le style par défaut), et la stocke donc dans les tables correspondantes : _point, _line et _polygon. Les éléments OSM d'origine sont dans les tables _nodes, _ways et _rels avec juste leurs tags et leurs membres. On pourrait ptet recalculer la géométrie à partir des membres dans l'api, à tester.
J'ai noté aussi que ça ne marche pas pour certaines way, par exemple
http://localhost:8080/api/osm?featureType=way&osmId=25033797qui a ungeometry{}. À l'inverse une way plus complexe comme celle-ci fonctionnehttp://localhost:8080/api/osm?featureType=way&osmId=17035273.Pour le way/25033797 c'est un landuse=residential sans aucun autre tag, donc je soupçonne (mais à vérifier) qu'il a été exclut par le filtrage par défaut (qui ne conserve que ce qui est utile pour calculer un fond de carte standard). Alors que le way/17035273 est un leisure=park donc clairement conservé.
Bon, en plus de la récupération presque instantanée des données d'un lieu (pour l'instant limité aux nodes), j'ai résolu des pb JS qui ajoutaient des latences inutiles.
Le clic sur un lieu devient presque instantané ! C'est très cool :)
Bon c'est bon, a priori, la base est MAJ toutes les minutes.
Donc sauf si j'ai introduit un nouveau bug dans cette PR, ça peut se mettre en ligne. @etienneJr n'hésite pas à tester si tu veux. C'est en ligne ici https://dev.cartes.app
Suite de la PR.
à terminer
Pour le way 17.5/48.111362/-1.678593">opéra de rennes, cette branche a plusieurs problèmes :
- il faut transformer la géométrie renvoyée par notre API OSM pour en déduire le centre pour centrer la carte, comme on le fait dans disambiguateWayRelation. Faisons-le déjà côté client pour l'instant
- l'appel de repli via Overpass, de toutes façon nécessaire pour les éléments qui ne sont pas dans noter API limitée à la France, semble poser problème, il n'a plus le "full" qui permet de montrer la géométrie : régression
Idem pour les relations.
- étendre le sitemap à d'autres régions, je crois que pour l'instant on n'a que la Bretagne
- recoder combinedOsmRequest pour les résultats de recherche
- il doit utiliser le même code que dans osmRequest>buildX
- l'occasion de revoir cette histoire de housenumber
- tester le mode itinéraire : la sélection des points semble cassée
à refaire dans une autre PR
-
if (tags['addr:housenumber'] && !tags['addr:street']) dans osmRequest
J'ai testé sur l'exemple en commentaire, ça ne marche plus sur cartes.app avant cette PR, à corriger
des bugs relevé sur dev.cartes.app via le canal Matrix
Je ne suis pas convaincus qu'ils soient dus à la nouvelle API, peut-être même le contraire, du aux latences / plantages des requêtes overpass. On aura le temps de les corriger après mise en ligne.
dokploy-2025-01-09-cartes[bot]
Dokploy Preview Deployment
Name Status Preview Updated (UTC) web-master ✅ Done Preview URL 2025-04-11T15:19:50.616Z @etienneJr je me suis embourbé dans une refacto (nécessaire) du code spaghetti qui gérait les features. Ça va me prendre du temps...