Le 24 février 2012 17:33, sly (sylvain letuffe) <li...@letuffe.org> a écrit : > On vendredi 24 février 2012, Philippe Verdy wrote: >> La base OSM ne retourne pas toujours non plus les ways > > La base OSM ne retourne rien, c'est un stockage, tu parles donc de l'API 0.6 > codée en ruby que l'on peut interroger par http://api.openstreetmap.org/api > et qui elle va chercher dans la base.
Oui, ne jouons pas sur le mots ici. Une base, n'importe laquelle, ne retourne rien, elle stocke, il n'y a que les requêtes qu'on y effectue, toujours via une API quelle qu'elle soit. >> qui traversent >> le rectangle mais sans y avoir aucun nœud dans ce rectangle. > > Ce n'est pas vraiment un bug car c'est voulu afin de limiter la charge du > serveur qui gère l'API qui est bien souvent déjà très occupée. > > Je suis d'ailleurs en train d'améliorer mon "proxy d'api" > (http://api.openstreetmap.fr/api) pour qu'il puisse supporter cette > fonctionnalité qui serait un plus. > >> Hors, les moteurs de rendu procèdent ainsi pour connaître les données >> à afficher dans un rectangle. > > non, ils utilisent l'opérateur && de PostGIS qui calcul l'intersection des > bbox avec le point de vue. Lequel opérateur, tu l'oublies, font tout de même ce genre de calcul, et peut aussi omettre les mêmes données. >> Bref, pour de tels cas, il n'y a pas d'autres moyens que d'affiner les >> tracés en ajoutant des nœuds, c'est possible pour les chemins, mais >> pas toujours concernant les libellés de nœuds qu'on ne peut pas >> déplacer. > > Il ne faut pas faire ça, l'amélioration doit être faite dans l'API. Il ne faut > pas rajouter des points inutiles dans le seul but de régler un problème > d'édition. Il n'y a techniquement aucun autre moyen que d'aller chercher des points hors de la zone demandée si on veut une liste complète. L'autre solution, c'est que les chemins liant les points aient eux-mêmes été indexés sur la totalité des tuiles qu'ils traversent, ce qui impose alors des calcul de points supplémentaires, là où ces chemins traversent les frontières de tuiles. On en revient au problème initial. La seule différence étant l'endroit où on stocke ces points supplémentaires nécessaires pour une couverture complète. D'ailleurs PostGIS augmente largement les données sources de données dérivées, qu'il stocke naturellement dans son propre schéma de base pour séparer les choses et faciliter les mises à jour ultérieures. Il n'empêche que ces points ajoutés augmente la volumétrie totale, même si elle améliore et accélère considérablement les recherches locales pour une couverture lus complète. Un opérateur lui-même ne fait rien de mieux : il peut utiliser les données issues de la base principale, mais comme cela ne suffit pas, il se sert aussi des données dérivées. La question étant alors comment et quand calculer ces données dérivées pour que cela ne surcharge pas toutes les requêtes ni que l'essentiel de la puissance de calcul soit consacré à mettre à jour en permanence ces données dérivées. C'est pas si évident que ça quand les données sources sont déjà particulièrement volumineuses. Tu noteras tout de même que les moteurs de vérification essaye de soulager la charge générale en identifiant les segments trop longs, sur lesquels il est hautement souhaitable d'augmenter la précision avec des points intermédiaires supplémentaires, afin d'éviter d'avoir toujours à rechercher des points très au delà de la zone de recherche demandée. Et dans ce cas il n'est pas absurde d'augmenter la précision des tracés selon la précision que l'on demande ensuite pour les rendus : indépendamment des styles de rendus, si on cherche à terme une précision métrique, il faudra ces points qui ne seront pas distancés au delà de quelques centaines de mètres au maximum de la zone de recherche. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
