FR:API v0.7

La version 0.7 de l'API est en cours de discussion sur la page en Anglais. La version 0.6 date de 2009.

API v0.7" est la version "suivante" de l'OSM API. À ce stade, nous réfléchissons à de nouvelles fonctionnalités ou à des modifications pour la version 0.7 de l'API.

Brainstorming

Le concept de Brainstorming signifie que chacun peut ajouter ses idées, même si elles sont stupides, et que les autres sont priés de ne pas dire immédiatement qu'ils trouvent l'idée stupide. Cette phase (éliminer les idées stupides) vient "après" le brainstorming. Veuillez consulter la liste ci-dessous à la lumière de cette remarque : S'il y a une personne dans le monde qui pense que toutes les étiquettes OSM devraient être exclusivement en chinois à l'avenir, alors la liste aura cette caractéristique. Rappelez-vous : il est très probable que 90% des idées ci-dessous soient aussi réalistes que "toutes les étiquettes OSM devraient être exclusivement en chinois à l'avenir", même si certaines sont clairement reconnaissables comme étant amusantes et d'autres sont réelles. Ce n'est pas une liste de choses à faire, mais une liste de pensées aléatoires d'une centaine d'utilisateurs. L'API 0.7 peut ou non mettre en œuvre certaines d'entre elles, et l'API 0.7 peut très bien mettre en œuvre d'autres choses qui ne figurent pas sur cette liste. --Frederik Ramm 22:24, 6 février 2011 (UTC)

Tout ne nécessite pas une nouvelle version de l'API

N'oubliez pas que tout changement qui peut être introduit sans perturber les clients existants ne doit pas attendre l'API 0.7, ou peut également être mis en œuvre à tout moment après l'API 0.7 et avant l'API 0.8 (ou 1.0 d'ailleurs). Les seules choses qui doivent être faites lors d'une mise à jour de version concertée sont celles qui rompent la compatibilité ou rendent indésirable la poursuite de l'utilisation d'anciens clients. Un simple "ajout de la fonctionnalité X" qui n'influence pas la façon dont tout le reste fonctionne n'a pas vraiment besoin d'être fait ici. L'une des étapes suivantes après le brainstorming consisterait à classer les fonctionnalités en (a) celles qui ne peuvent être mises en œuvre qu'avec un changement d'API et (b) les autres ; ensuite, un sous-ensemble de (a) sera sélectionné pour la version 0.7 (plus de nombreuses choses qui ne figurent pas sur cette liste mais que les personnes concernées proposent au pub la veille du changement), et certaines choses de (b) pourraient également être ajoutées mais elles ne seront en aucun cas critiques.

ÉGALEMENT : Peut-être devrions-nous séparer "API" de "modèle de données". L'API a quelques appels inspirés par le modèle de données (comme /node/1234 etc.) mais la plupart ne dépendent pas vraiment du modèle de données, et vice versa.

Nouvelles fonctionnalités

Supprimer les traces GPS en zigzag

Certaines traces GPS sont inutiles. Les traces avec un GDOP élevé vont partout, au-dessus des bâtiments, hors des routes. Dans les lieux très fréquentés, il y a des traces en zigzag (comme des enfants qui griffonnent leur première écriture), ce qui rend difficile le traçage normal. Il devrait y avoir un mécanisme permettant de supprimer la partie zigzaguée des traces.

Une histoire plus intelligente

Lorsque deux voies sont fusionnées, une seule histoire est sauvegardée (dans le meilleur des cas). Lorsqu'une voie est divisée, une seule voie contient l'historique.

Il serait préférable que les objets contiennent des informations supplémentaires. Quelque chose comme une nétadonnée "comes_from".

Par exemple, si vous fusionnez les chemins avec les identificateurs 1111 et 2222 (disons qu'ils sont tous deux à la version 5), le chemin 2222 sera supprimé et la prochaine version du chemin 1111 aura comme métadonnées "comes_from="2222:5"" (chemin 2222, version 5).

Lorsque vous consultez l'historique, vous arrivez à la version 6 de la voie 1111, et vous voyez que vous pouvez choisir l'identifiant qui suivra l'historique ultérieur de la voie 1111.

Cela fonctionne également lorsque vous fusionnez plus de deux voies, dans ce cas, il suffit de diviser les valeurs par un ';'.

Si vous divisez à nouveau la voie 1111, vous créez une nouvelle voie avec l'identifiant 3333, et cette voie obtient les métadonnées "comes_from="1111:6"" (voie 1111, version 6). Ainsi, lorsque vous arrivez à la version 1 de la voie 3333, vous pouvez creuser plus loin dans l'histoire via la voie 1111.

Tout comme l'identifiant de l'utilisateur et l'horodatage, le "comes_from" doit être lié à la version. Ainsi, s'il existe une nouvelle version d'une voie, sans fusion ni scission, les métadonnées "comes_from" doivent être vides. --Sanderd17 15h45, 23 janvier 2013 (UTC)

Cela semble être la même chose que #Garde l'histoire à la scission d'un élément. --Aseerel4c26 ([[Discours de l'utilisateur:Aseerel4c26|talk]) 17:24, 11 février 2015 (UTC)

Téléchargement de relations plus intelligentes

Les sessions d'édition longues deviennent de plus en plus dangereuses car vous modifiez toujours beaucoup de relations (routes, multipolygones) et les conflits dans l'upload sont généralement difficiles à résoudre avec les éditeurs actuels. Au moins pour JOSM, je ne vois pas de changement à ce sujet dans un avenir proche. Beaucoup d'utilisateurs abandonnent leur travail à ce stade et le redémarrent ou le laissent tomber.

Il existe une solution assez simple, qui pourrait améliorer considérablement la situation. Les systèmes de contrôle des révisions du code source ont le même problème, à savoir que plusieurs personnes travaillent sur le même objet. Au lieu d'une approche basée sur les fichiers, ils sont passés à une approche basée sur les lignes. Cela signifie que les modifications dans le même fichier sont jointes tant qu'elles sont à xxx lignes (typiquement quelque chose autour de 5).

La même approche fonctionnerait pour les relations. La suppression ou l'ajout de nouveaux éléments pourraient être traités séparément lorsque les éléments modifiés sont suffisamment éloignés les uns des autres. Dans ce cas, les deux modifications pourraient être effectuées sans conflit. Le résultat serait une relation combinée signalée au rédacteur en chef. Si les changements sont trop proches (ou si la relation a été totalement retravaillée), un conflit peut être publié comme c'est le cas actuellement.

Flux de travail théorique (version tueuse de performance :-) pour le téléchargement d'une relation :

• télécharger une nouvelle relation
• si le serveur n'est pas de la même version que la nouvelle

* enregistrer la nouvelle relation dans le fichier new.rel
* enregistrer l'état du serveur dans server.rel
* sauvegarder l'ancienne version de l'état du serveur dans oldserver.rel
* faire un "diff -u oldserver.rel new.rel >diff"
* faire un "patch <diff server.rel"
* si aucun conflit, télécharger le fichier patché server.rel au lieu du nouveau .rel

Comme la différence peut être faite du côté du client auparavant, nous pouvons réduire considérablement cette différence et aussi économiser beaucoup de bande passante (surtout pour les relations importantes) :

• Envoyer un "diff -u" comme relationupdate-request
• l'appliquer et signaler le conflit uniquement lorsque le patch ne fonctionne pas, sinon signaler le nouvel état.

BTW : Le téléchargement des différences peut également être une option pour d'autres objets volumineux (moyens) d'économiser de la bande passante (probablement sans possibilité de l'appliquer à la version non correspondante). --Stoecker] 20h55, 22 novembre 2012 (UTC)

Zones

Le soutien aux domaines de la chaîne d'outils OSM est encore faible, bien que ceux-ci soient importants. Par exemple, des idées comme downloading an area ou country specific rendings nécessitent l'existence de polygones de frontière pour les pays.

Mais ces frontières sont souvent perturbées par des erreurs d'édition. Par exemple, the boundary relation of Germany n'était pas disponible pendant la majeure partie du mois de janvier. D'autres relations comme frontière de la France ont des formats spéciaux en raison de leur énorme complexité.

Je suggère un type de données qui permet des approximations. Par exemple, un polygone à six sommets pourrait entourer l'"hexagone" France suffisamment pour répondre à la question de savoir quelles autoroutes sont en France et lesquelles ne le sont pas :

<relation id="11980"> <Polygone limitrophe> <coord lat="51.5" lon="2.5"/> <coord lat="48.5" lon="-6.5"/> ... </bounding-polygon> <intérieur> <coord lat="51.0" lon="3.0"/> <coord lat="48.5" lon="0.0"/> ... </intérieur> <member type="way" ref="..."/> ... </relation>

On peut maintenant en déduire que Paris est en France même si la frontière a un trou quelque part à Nice.

Comme il ne s'agit pas de nœuds basés sur un objet réel, ils ne devraient pas être des nœuds à part entière. Les avoir comme valeurs dans les balises ne fonctionnera pas car elles dépassent facilement 255 octets. Une dérivation automatique du polygone prévu peut ne pas fonctionner dans tout cas avancé ou devenir très complexe, voir Multipolygone.

Les zones ont besoin de leur propre primitive de données car la définition d'une manière fermée comme aujourd'hui est sujette à erreur. De même, toutes les voies fermées ne sont pas des zones, comme le montre l'exemple de roundabouts.

Couches

Prise en charge de couches afin que les éditeurs ne reçoivent que certains types de données pour limiter la charge de travail sur les clients et le serveur.

Il suffit de permettre à l'API de filtrer des choses, comme le fait OSMXAPI. Et gardez à l'esprit qu'un nœud peut être partagé entre, disons, une route et une clôture... donc si l'une de ces caractéristiques n'est pas incluse dans les données téléchargées, elle doit être marquée d'une manière ou d'une autre, pour le faire savoir à l'éditeur. --Ivansanchez 10:41, 2 février 2010 (UTC)

Je sais que ce sera un PITA à stocker, mais en théorie une requête de base de données peut renvoyer une liste d'objets dont un noeud est membre, de cette façon l'éditeur peut savoir si un noeud a d'autres liens que ce qui est dans la mémoire. D'autre part, cela peut augmenter la charge de la mémoire si l'éditeur est presque aussi gros que si toutes les informations étaient présentes, de sorte que la partie de la charge de travail du logiciel (côté client et côté serveur) ne soit pas modifiée. Pour l'utilisateur, d'autre part, lors de l'édition dans des zones où le niveau de données est élevé, il peut être avantageux de filtrer certaines parties des données. --Skippern] 21:53, 4 mars 2010 (UTC) Comme les données sont stockées différemment sur le serveur et dans les fichiers XML couramment utilisés par les éditeurs, une valeur XML supplémentaire peut être ajoutée pour indiquer si un objet a des liens invisibles lorsque des couches sont utilisées. Par exemple, un nœud peut avoir <binding way="id#1,id#2" relation="id#3"/> indiquant à l'éditeur que si ce nœud est modifié, les chemins #1 et #2 et la relation #3 doivent être consultés avant le téléchargement. --Skippern] 21:18, 25 février 2012 (UTC)

Utilisateurs "vérifiés" / Balises verrouillées

Certains éléments cartographiques de l'OSM (par exemple les frontières) ont une autorité qui désigne officiellement ou légalement leur emplacement ou leur chemin. Ces éléments ne doivent pas être autorisés à se déplacer, sauf par des utilisateurs vérifiés.

Cela va à l'encontre de l'idée d'OSM, qui est que tout le monde peut améliorer un objet. Vous pouvez vous débarrasser de vos objets ou créer votre propre base de données si vous ne voulez pas qu'ils soient modifiés. Cela ne provoquera que des litiges, à savoir quel objet doit être verrouillé et à qui sont donnés les droits de les modifier. C'est donc une mauvaise idée. --Fabi2 19:33, 9 février 2011 (UTC)

Cela peut être mis en œuvre sans changer l'esprit de l'OSM. Certaines fonctionnalités pourraient être marquées d'un "X" et les éditeurs avertiraient l'utilisateur avant de les modifier. Il s'agirait d'un mécanisme permettant d'éviter les modifications non souhaitées, mais sans limiter le nombre de personnes qui souhaitent réellement les modifier. Les caractéristiques non physiques, comme les frontières administratives, pourraient avoir ce comportement. L'approche que je propose n'a aucun impact sur l'API. Utilisateur:jgrocha, 10-Sep-2011

: Pas besoin d'implémenter le "X" dans l'API. Chaque éditeur peut adapter son avertissement en fonction de la base d'utilisateurs. Par exemple, Level0 a besoin de moins d'avertissements ;)--Jojo4u. (talk) 23:39, 29 septembre 2016 (UTC)

: Un tel "verrou" devrait également être disponible en option pour d'autres étiquettes. Par exemple, si quelqu'un est absolument sûr que l'information est correcte, il pourrait "fermer le verrou" pour empêcher un cange par erreur (il peut être déverrouillé par une confirmation (comme décrit par User:jgrocha) et peut-être que l'utilisateur du verrou reçoit un message). Il devrait être possible de verrouiller seulement une des "caractéristiques" d'un nœud/voie/..., y compris la possibilité de ne verrouiller que la latitude-postition d'un nœud mais de laisser la longitude-position déverrouillée. (désolé pour mon mauvais anglais...) --rayquaza 06:02, 28 juin 2012 (BST)

: Toute information peut changer, même les dérives latentes/longues des points avec les continents... [User:Jojo4u|Jojo4u]] (talk) 23:39, 29 septembre 2016 (UTC)

Les outils de surveillance peuvent signaler les modifications apportées à des objets particuliers tels que les limites des frontières et les lignes de côte. Voir, par exemple, Watch pierzen 20:53, 23 octobre 2012 (BST)

Je suis également d'accord sur le fait que le verrouillage des objets n'est pas (actuellement) la bonne solution. Il existe d'autres possibilités comme les campagnes de surveillance (par exemple pour les frontières mondiales sur le forum allemand), ou le prétraitement des données (par exemple littoraux) Jojo4u. (talk) 23:39, 29 septembre 2016 (UTC)

Lock régions=

J'aimerais que l'API 0.7 puisse verrouiller les (petites) régions si je les modifie. Si un autre utilisateur veut les modifier, il ne peut pas le faire si elles sont verrouillées. Cependant, une région d'un kilomètre carré au maximum devrait être verrouillée par un utilisateur et il ne devrait pas y avoir plus d'un verrouillage d'une durée maximale d'une heure.

En option, un verrou peut être un simple avertissement, indiquant que quelqu'un d'autre est déjà en train de modifier la zone.

Fonctionnalité de verrouillage

Pour prévenir le vandalisme, la section locale ou un groupe de cartographes locaux expérimentés diraient que, par exemple, les autoroutes sont terminées dans une zone donnée. Personne ne serait autorisé à modifier/ajouter de nouvelles autoroutes. Pour changer ce cadenas, le même groupe enlèverait ce cadenas. Cela empêcherait les cartographes inexpérimentés de commettre les plus grosses erreurs, les trolls de dessiner des noms avec les autoroutes et les experts en marketing de créer des villes à partir de pubs.

L'écluse comprendrait

• zone (multipolygone)
• les types d'éléments qui sont finis
• peut-être que seule la géométrie est verrouillée et que de nouvelles balises sont possibles (par exemple, d'autres noms de langue)

exemples :

• un pays et un lieu = ville
• région et autoroute=motorway|trunk
• frontières des pays et des régions
• frontières de la région et de la côte

MichalP 14:31, 25 février 2012 (UTC)

Il s'agit en réalité d'un DoS sur les mises à jour ! Ce problème devrait être résolu par un meilleur suivi des changements et des systèmes de retour en arrière. --Fabi2 01:09, 26 février 2012 (UTC)

: Pas sûr, de temps en temps quelqu'un change le nom d'une ville (volontairement) ou détruit les frontières (généralement par accident). Cela prend beaucoup de temps et est très ennuyeux. L'IMHO en aura besoin tôt ou tard. -- [User:MichalP|MichalP]] 17h15, 28 mars 2012 (BST)

Surveillance

Les utilisateurs doivent pouvoir surveiller une boîte de délimitation ou un ensemble d'éléments et être avertis lorsque quelqu'un les modifie. De cette façon, les modifications seront vérifiées plus rapidement par les cartographes locaux et il y aura moins de vandalisme.

+1 de ma part ! --Lulu-Ann] 16:09, 16 décembre 2009 (UTC)

+1 et nous permettre de nous y abonner avec le RSS --Skippern 18:49, 17 décembre 2009 (UTC)

+1 --Neic] 01:27, 3 juillet 2010 (UTC)

+1 --Don-vip] 14:51, 17 avril 2011 (BST)

+1 --User:amritkarma] 2 novembre 2013

+1 Cela aurait été bien s'il y avait quelque chose de similaire à https://wiki.openstreetmap.org/wiki/Special:Watchlist pour voir si les voies/nœuds auxquels je suis abonné ont changé. --Magol] 10h05, 30 janvier 2012 (UTC)

J'ai fait un travail de surveillance. Voir : [1] , [2] -> ticker et [3]. Les premiers sont également destinés à la surveillance en direct. Les données proviennent de différences infimes. Les données sont réduites et mises en cache sur mon serveur, puis transférées au client. Il n'y a pas de possibilité de réduction de bbox par cette méthode. Le troisième outil utilise les changements d'api. Le changeetS api donne trop de résultats (bots ... comme décrit ci-dessous). Cette api est également lente sur les bbox de taille moyenne. Après avoir chargé les jeux de modifications, je charge les données de l'api des jeux de modifications. Un changeet n'est jamais modifié et il serait très facile de les mettre en cache. Pour un bon hitrate, ce cache devrait être fourni par osm, peut-être de la même manière que les différences de minutes. Un fichier de modification ne contient pas toutes les données nécessaires pour une visualisation complète. Il manque des points dans les modifications et cela doit être chargé dans une étape supplémentaire, ce qui rend tout le processus lent. Il devrait y avoir une option pour un jeu de modifications "complet".

Il me serait possible de créer une interface utilisateur de surveillance agréable. Si les utilisateurs l'apprécient, l'API serait le goulot d'étranglement. Il est très probable que mon adresse IP soit bloquée. Tout d'abord, l'OSM doit encourager les développeurs à utiliser [4]. Si la base de données est trop lente pour cela, nous pouvons oublier toute surveillance. Le deuxième problème est qu'il n'y a pas de problème technique. Il suffit de prouver que les modifications sont des fichiers comme les différences minute par minute et de mettre plus d'informations à l'intérieur.

Cela est possible grâce à la fonction RSS de WhoDidIt Jojo4u. (talk) 23:29, 29 septembre 2016 (UTC)

J'ai développé une application pour le suivi. Il s'agit d'une application C++ qui utilise des différences infimes et des modules d'analyse. J'ai actuellement un module dédié au monitoring qui peut être utilisé pour surveiller tous les changements liés aux objets qui ont été édités par un utilisateur spécifique. Le module peut également être initialisé avec le résultat d'une requête API Overpass par exemple. Si vous souhaitez plus d'informations, n'hésitez pas à me contacter grâce à la messagerie OSM --quicky

+1 pour une simple liste de surveillance sur des objets particuliers Fanfouer]. ([[Discussion entre utilisateurs:Fanfouer|talk]) 12:44, 13 août 2013 (UTC)

180e méridien

Peut-être en permettant aux nœuds d'avoir une longitude un peu plus grande que 180 pour permettre aux moyens de se connecter correctement et faire un peu de magie dans les getters pour les faire apparaître sur la longitude 0.

Pour que la ligne de date et les frontières qui traversent le 180 puissent être correctement gérées par l'API, le routage et le rendu sans contournement. Permettre aux requêtes de franchir le 180 de manière transparente, c'est-à-dire avec des valeurs de bbox >180 --Skippern]. 18:52, 17 décembre 2009 (UTC)

+1 Voir https://trac.openstreetmap.org/ticket/1612 et https://josm.openstreetmap.de/ticket/2212 --Don-vip] ([[Parole d'utilisateur:Don-vip|talk]) 09:50, 30 octobre 2013 (UTC)

+1 Que Google n'a pas d'autoroutes autour de 180° ne devrait pas nous empêcher de les cartographier là sans lacunes à des frontières artificielles -- malenki 11:24, 20 juillet 2014 (UTC)

Pas de nouvelles primitives

Parfois, "laisser l'enfer tranquille" est une vertu.

Nous avons des nœuds, des voies, des relations. Ils peuvent être utilisés pour à peu près tout ce que vous voulez. Nous avons l'intégrité des données grâce aux changeurs. Toute autre modification du modèle de données distrait notre groupe limité de développeurs des choses importantes (interface utilisateur, performances) uniquement pour satisfaire architecture astronautes. Même les changements qui semblent insignifiants pour un développeur, par exemple les relations de commande, peuvent être extrêmement perturbateurs pour d'autres projets dont l'interface utilisateur ne fonctionne pas de la même manière que celle du projet du développeur d'origine.

D'autres nouvelles primitives

Nous devons inventer de nouvelles primitives pour nous assurer que seuls les meilleurs logiciels survivent - des logiciels dont la communauté de développeurs est suffisamment forte pour accepter le changement et les nouvelles opportunités qu'il apporte. Les logiciels dont les programmeurs se plaignent de devoir apporter un changement méritent de mourir, ou d'être interdits. Nous sommes trop jeunes pour un rejet total du changement. J'aime le concept de Circus Maximus ou {Colosseum où les "codificateurs" (mélange de codeur et de gladiateur) luttent contre des virus représentés par des lions... pas mieux : des dragons ! --Bahnpirat 15:04, 17 mars 2010 (UTC)

Protocole binaire

Bien que nous aimions le protocole xml actuel, il est source de nombreux problèmes dans certains scripts. Le xml doit être analysé en mémoire et écrit dans le fichier de sortie. Cela prend beaucoup de CPU, de mémoire, d'espace et de transfert. Si nous parvenons à créer un protocole binaire, nous pourrions éliminer la plupart des problèmes d'analyse et d'espace. Un protocole binaire peut être meilleur que le gain de 90% que nous obtenons aujourd'hui si nous gzipons les fichiers xml. Et de nombreuses applications peuvent économiser de la mémoire et du temps de chargement en utilisant le protocole binaire en interne. Il sera ainsi plus facile de réaliser des programmes plus rapides en C, C++, D, Java et autres langages de programmation de bas niveau, au lieu des langages de haut niveau dans lesquels la plupart des programmes sont écrits aujourd'hui. L'un des arguments les plus utilisés aujourd'hui pour utiliser perl dans OSM est l'analyse facile de xml. Je suis d'accord avec la nécessité d'un protocole binaire, mais ce n'est pas le rôle de l'OSM d'en "faire" un : EXI a récemment été publié en tant que recommandation W3C. L'OSM devrait utiliser une implémentation existante de ce protocole. --Don-vip 14:58, 17 avril 2011 (BST) Le format choisi actuellement est le Pbf, mais il n'est pas disponible par l'API, seulement sous forme de fichiers Jojo4u. (talk) 23:47, 29 septembre 2016 (UTC) Ou un protocole de texte en JSON. JSON est plus facile à analyser que XML. J'aime les protocoles texte parce qu'ils sont attrayants : on peut les comprendre et les manipuler plus facilement. -M!dgard] [ talk ] 10h35, 29 janvier 2018 (UTC)

Modifications anonymes=

Beaucoup d'utilisateurs veulent juste éditer une petite partie de la carte et ne pas avoir à s'enregistrer. Pourquoi ne pas faire comme wikipedia et autoriser les modifications anonymes jusqu'à une certaine limite. L'adresse IP sera stockée et, après un nombre x de modifications des objets, elle sera interdite et l'utilisateur devra s'inscrire pour contribuer davantage. Il s'agit d'une alternative à openstreetbugs et peut ne pas être nécessaire si openstreetbugs est plus visible pour le public.

La désactivation des modifications anonymes a été une décision réfléchie en 2007. La discussion de cette époque devrait en expliquer les raisons. Alv 18:08, 28 février 2010 (UTC)

: Il ne s'agit pas du même type de modifications anonymes. Je suggère de permettre aux utilisateurs de modifier la carte avec un accès limité ou de télécharger des pistes sans avoir à créer un compte. Tout comme wikipedia. Gnonthgol 18h30, 28 février 2010 (UTC)

: Les éditeurs anonymes devraient pouvoir modifier leur propre vision du monde. Si quelqu'un ajoute un bâtiment, il aura ce bâtiment sur sa carte jusqu'à ce qu'il supprime le navigateur.

Si l'utilisateur veut contribuer à l'OSM, il devrait pouvoir s'inscrire après avoir édité. Si l'utilisateur a finalement un compte, il peut par exemple envoyer ses fichiers gpx collectés à OSM. L'API n'a pas besoin d'être modifiée pour cela.

JOSM l'a en quelque sorte déjà implémentée (l'utilisateur peut éditer autant qu'il le souhaite, mais ne peut télécharger qu'après s'être inscrit). Peut-être que Potlatch devrait avoir une approche similaire ? Laisser les gens éditer autant qu'ils veulent, peut-être même l'enregistrer comme un fichier OSM-diff, mais n'appliquer les changements qu'après s'être enregistré ? (Évidemment pas lié à l'API) --Skippern 02:09, 22 mars 2010 (UTC)

Undelete/undo=

Un véritable "undelete" serait bien, de sorte qu'il serait possible de conserver l'ancienne histoire de l'objet. Si l'annulation était implémentée comme une annulation, elle fonctionnerait également sur les objets visibles, les ramenant à la version précédente sans avoir à spécifier explicitement toutes les balises, etc. de l'ancienne version.

+1 Ceci est définitivement nécessaire puisque les modifications de l'API 0.6 se sont produites pendant le processus de rédaction. Ces changements ont essentiellement tué les deux plugins JOSM (non maintenus) qui fournissaient cette fonctionnalité. Un mécanisme natif d'annulation/rétablissement fourni par l'API ne serait pas affecté par un changement futur de l'API. --Don-vip 22:27, 3 octobre 2012 (BST)

Pour remédier au vandalisme et aux erreurs, au moins deux fonctions minimales pourraient être ajoutées :

• un moyen de retrouver les objets supprimés dans une zone donnée (c'est-à-dire en délivrant le dernier état non supprimé)
• une façon de demander une certaine "date" de l'ensemble des données (c'est-à-dire sans connaître un objet ou un ensemble de modifications particulier)
• les deux pourraient être combinés.

--Stoecker] 20:37, 22 novembre 2012 (UTC)

Précision et élévation

Ajoutez les nouveaux attributs "hauteur" et "précision" dans l'élément de nœud. height" doit être l'altitude brute WGS84. La "précision" est fournie par certains GPS ou par d'autres sources de données. Elle peut être définie par les éditeurs lorsque la source est connue (par exemple, l'imagerie Yahoo). Les deux peuvent être nulles si elles sont inconnues.

Les éditeurs pourraient émettre un avertissement si quelqu'un déplace des données existantes vers une nouvelle position lorsque la nouvelle source est signalée comme étant moins précise que la précédente.

Lorsque l'altitude est connue, nous pourrions éviter certaines balises "haut/bas" ou valider les données par rapport aux MNE. --[Utilisateur:Pieren|Pieren]] 13:21, 26 mars 2010 (UTC)

Un bon début peut être de permettre aux pistes GPX de stocker des données HDOP, et de permettre aux utilisateurs de filtrer ces données, si nous autorisons également quelque chose dans la même ligne dans les nœuds, que nous avons la précision stockée dans la base de données. La question est de savoir comment nous devons traiter les millions de nœuds déjà présents dans la base de données. Les élévations devraient être traitées de manière complètement différente, c'est-à-dire comme des coordonnées du troisième axe. --Skippern 22:53, 15 mai 2010 (UTC)

Est-ce la même chose que d'ajouter une coordonnée Z aux nœuds ? BigPeteB 15:06, 13 juillet 2010 (UTC)

unicité dans les relations

Un attribut doit être défini dans l'élément relation pour activer/désactiver une contrainte d'unicité sur les membres de la relation lorsque les valeurs en double ne sont pas les bienvenues. Les éditeurs et les contributeurs ne sont pas conscients de cette possibilité et cela crée des doublons non souhaitables lorsque cette possibilité a été introduite pour un très petit sous-ensemble de relations. --[Utilisateur:Pieren|Pieren]] 13:21, 26 mars 2010 (UTC)

Faciliter le suivi des objets parents

Il serait bon de pouvoir savoir si un nœud a fait partie d'un chemin ou d'une relation dans le passé (et de même pour les chemins appartenant à une relation). Actuellement, il est facile d'obtenir l'information de la relation grâce à l'historique de la relation, mais il n'est pas possible de former le chemin ou le nœud lui-même sans avoir déjà l'information. -- quicky] 2:29, 3 Jan 2013 (UTC)

Tags pour les membres de la relation. Le rôle n'est pas suffisant

Par exemple, pour cartographier les bâtiments qui ont de nombreuses adresses :

<relation id="-1"> <member type="way" ref="-10" role="address"> <tag k="addr:housenumber" v="10/2"/> </membre> ... <tag k="type" v="street"/> <tag k="addr:street" v="Street 1"/> </relation> <relation id="-2"> <member type="way" ref="-10" role="address"> <tag k="addr:housenumber" v="2/10"/> </membre> ... <tag k="type" v="street"/> <tag k="addr:street" v="Street 2"/> </relation>

-- [User:Liosha|Liosha 15h35, 3 juin 2010 (UTC)

Cela peut être corrigé en marquant les adresses des entrées. Utilisateur:Lulu-Ann

: Non, ce n'est pas possible. Beaucoup de maisons ici ont des adresses dans plusieurs rues, et toutes les entrées ont des numéros de maison. Alv 09:53, 4 juin 2010 (UTC)

On ne peut pas le faire avec des relations multiples ? --Skippern] 22:26, 4 juin 2010 (UTC)

: Je disais juste que les numéros de maison sur les nœuds d'entrée ne résolvent pas le problème. Des relations multiples rendraient cela possible. Alv 12:06, 6 juin 2010 (UTC)

: C'est possible : par exemple, vous pouvez créer une relation spéciale "house_address" qui a pour membre addr:housenumber tag et building, et qui est elle-même membre de street relation. Mais je pense que cette façon de faire est trop complexe pour une édition confortable. Les balises pour les membres est une meilleure façon --Liosha] 09:47, 6 juin 2010 (UTC)

+1 --Gorm] 15:05, 7 juin 2010 (UTC)

Les tags pour les membres rendraient vraiment la vie plus facile dans de nombreux cas. --Komяpa] 16:48, 15 juin 2010 (UTC)

Je pense aussi aux lignes de bus de PT. Les horaires les plus simples ont des heures de départ et un temps de trajet fixe pour atteindre un certain arrêt. Dans ce cas, les heures de départ pourraient être encodées sous forme de balise sur la relation, et chaque arrêt pourrait recevoir une heure indiquant le temps qu'il faut pour vous rendre du départ à cet arrêt. C'est possible avec des rôles, bien que très maladroits. L'encodage d'un horaire comme celui-ci utilise un minimum de stockage d'informations (pas un tableau complet en 2D, mais seulement des valeurs uniques), ce qui le rend assez facile à adapter. Même sans les heures de départ, c'est pratique, car il devient facile de calculer le temps de trajet d'un arrêt à l'autre. --Sanderd17 ([[Parole d'utilisateur:Sanderd17|talk]) 16:31, 11 février 2015 (UTC)

Les moyens ne sont que de simples relations

Pourquoi ne pas supprimer les moyens comme un primitif et les mettre en œuvre comme un sous-ensemble de relations ? Cela peut être fait de manière transparente pour l'utilisateur en ayant une sorte de this_relation_is_really_a_way=yes cachée et en ne servant que les voies étiquetées avec elle lorsque l'utilisateur demande des voies. Hm... Cela ne nécessiterait même pas un changement d'api, mais quand même... --Gorm 15:05, 7 juin 2010 (UTC) Cette relation est vraiment différente, ce qui implique que : 1) seuls les nœuds peuvent apparaître comme membres, et 2) les membres (nœuds) n'ont pas de "rôle". Ainsi, bien que vous puissiez considérer les voies comme une sous-classe spéciale de relations (ou elles peuvent être juste cela dans un sens mathématique), elles forment une sous-classe si fortement restreinte qu'il est plus sage de les mettre en œuvre séparément, ce qui évite également certains frais généraux. -- Oli-Wan 07:48, 6 novembre 2010 (UTC) Quel serait le bénéfice de cette folie ? Bulwersator ([[Discours d'utilisateur:Bulwersator|talk]) 12:28, 2 novembre 2013 (UTC)

Soutien à la 3e dimension

La 3ème dimension est jusqu'à présent uniquement supportée par les balises height=<number> et ele=<number> et proposée levels. Mais il y a des choses qui ne sont pas traitées de manière agréable.

• Il n'y a pas de disposition pour un modèle numérique d'élévation (MNE)
• Il n'y a pas de dispositions pour les objets 3D comme les bâtiments qui peuvent avoir des hauteurs différentes.
  • Les bâtiments peuvent avoir plusieurs parties de hauteur différente / nombre de niveaux.
  • Plus complexes encore sont les cathédrales avec des nefs principales et latérales, un transept, une abside et sans oublier la ou les tours.
• Plusieurs objets en dessous ou au-dessus les uns des autres comme un parking en dessous d'un magasin ou un parking au-dessus d'un magasin, c'est-à-dire sur le toit du magasin.

Le point "plusieurs parties" est couvert par Simple_3D_buildings].--Jojo4u ([[Parole d'utilisateur:Jojo4u|talk]) 00:00, 30 septembre 2016 (UTC)

Le problème ci-dessous/supérieur est actuellement résolu pour certains cas courants mais pas de manière générale. Par exemple, parking=toit ou location=sous-terre pour les pipelines.--Jojo4u] ([[Parole d'utilisateur:Jojo4u|talk]) 00:00, 30 septembre 2016 (UTC)

Décoration

Une étape intermédiaire pourrait être l'introduction de décorations pour les bâtiments, qui pourraient être utilisées pour dessiner une représentation en 2D de la forme d'un bâtiment ou d'un toit.

Il s'agit plutôt d'une question de marquage et devrait être couverte par Simple_3D_buildings now( ?)--Jojo4u (talk) 23:56, 29 septembre 2016 (UTC)

Soutien aux données temporelles

Il existe quelques utilisations des données de temps pour la restriction d'accès (date_on/off/...) et pour la modélisation des heures d'ouverture (magasins, restaurants, bureaux, stations-service, ...). La demande suivante concerne les données horaires pour les transports publics, c'est-à-dire le support des horaires. Il devrait y avoir un système permettant de traiter toutes les données horaires de manière congruente.

Caractéristiques proposées/Programmes de transport public est un début.

Valeurs par défaut pour une zone

Dans Relations/Proposed/Defaults se trouve une proposition sur la façon de marquer les valeurs par défaut des relations, principalement des zones définies par une frontière. Cela inclut des choses comme les lois de circulation spécifiques à un pays, les jours fériés spécifiques à un état, les règlements spécifiques à une ville et d'autres règlements. Bien que cette proposition ne soit pas la meilleure façon de traiter les réglementations spécifiques à une zone, elle montre la nécessité de traiter des informations implicites. Voir aussi #Classes dans ce document.

Commentaires dans les listes de membres d'une relation

Une relation peut avoir des membres importants (quelques centaines) ou très importants (plus de mille). Il est nécessaire de donner une structure à ces grandes listes de membres. Un commentaire est une entrée dans une liste de membres, qui ne fait référence à aucun objet mais donne simplement des informations supplémentaires sur le type/la nature des membres suivants. Exemples :

• Une relation définissant une limite pour l'objet AAA pourrait trier les membres de telle sorte que toutes les façons de définir la partie de la limite qui est commune avec la limite de l'objet BBB soient mises dans une séquence qui est précédée d'un commentaire indiquant quelque chose comme "limite entre AAA et BBB".
• Une relation pour un itinéraire de transport public peut organiser la position de l'arrêt et les plateformes en sections du début à un nœud d'échange central à un autre nœud d'échange important jusqu'à la fin de l'itinéraire. Chaque section est précédée d'un commentaire décrivant la section suivante.
• Une relation décrivant le parcours d'une longue autoroute peut être divisée en sections par l'utilisation de commentaires. Les commentaires permettraient ainsi d'indiquer qu'il y a des parties non encore construites qui ne peuvent donc pas faire partie de la relation.

Il n'est pas essentiel d'avoir des commentaires dans une liste de membres mais il est important d'avoir un outil pour donner à une liste de membres une structure arbitraire. Un commentaire à cet égard n'est qu'un séparateur visible et non une véritable structure.

Recherche de pistes GPX

Nous devons pouvoir rechercher les GPX-Tracks qui remplissent certains critères tels que le nom, la description et les balises. Il faut également inclure les pistes qui croisent certaines zones ou se trouvent à une certaine distance d'une position demandée.

Cela doit également inclure la recherche de pistes ayant un certain âge (plus récent que la construction)

Tags multiples

L'API doit accepter la même balise plusieurs fois (à nouveau) et toute la chaîne d'outils doit être modifiée en conséquence. Cela résout l'ensemble de "brand=VW;Kia" d'une manière agréable : "brand=VW, brand=Kia".

Il y a beaucoup de choses internes qui ne supportent pas cela, comme le magasin Posgres, mais cela pourrait être résolu en compressant les multiples balises en une seule au moment de l'importation (par exemple dans osm2pgsql ou osmosis), mais la base de données principale devrait le supporter. MaZderMind 16h10, 11 octobre 2010 (BST)

Segments courbes pour les voies

Actuellement, les segments de chemin sont des lignes droites. Mais de nombreux objets dans le monde sont arrondis - une courbe de chemin de fer ou de route d'un certain rayon.

Les gens utilisent donc soit beaucoup de nœuds pour obtenir une bonne précision au prix de l'espace, soit seulement quelques nœuds - au prix de la précision. On pourrait utiliser des courbes de bézier. X-Plane 10 utilise les données OSM pour créer des routes et un trafic réalistes. Ils ont donc mis en place un outil qui crée des courbes de bézier à partir de données OSM (voir le blog des développeurs : Cliquez ici). Bien sûr, je ne suggère pas de convertir les données existantes, mais de mettre en œuvre quelque chose comme des courbes de bézier (ce qui pourrait être fait avec une relation si des structures existantes devaient être utilisées) afin que les utilisateurs puissent créer des courbes fluides. Des outils comme JOSM pourraient mettre en œuvre des fonctions permettant de créer une méthode en utilisant d'abord des nœuds, puis de sélectionner certains nœuds, d'appuyer sur "create curve" et JOSM tente d'optimiser ces nœuds en matière de nombre de nœuds en utilisant des courbes de bézier. L'utilisateur peut ensuite régler la courbe et la télécharger --LetzFetz]. 23:51, 30 août 2011 (BST)

Exemple

Par ici :

<voie ...>
 <nd ref="A" />
 <nd ref="B" />
 <nd ref="C" />
 <nd ref="D" />
 <nd ref="E" />
</way>

Pourrait devenir une voie avec segment entre C et D formant un arc de cercle :

<voie ...>
 <nd ref="A" />
 <nd ref="B" />
 <nd ref="C" />
 <nd ref="X" type="circle" />
 <nd ref="D" />
 <nd ref="E" />
</way>

Données techniques

Techniquement, chaque référence de nœud recevra un drapeau supplémentaire dans la base de données (est/n'est pas un point circulaire)

Bien que certaines courbes plus universelles, comme les courbes de Bézier, puissent être meilleures, elles peuvent dérouter les débutants, car il n'est pas toujours simple de manipuler les points de contrôle pour obtenir la courbe souhaitée. Mais je pense que tout le monde comprend les cercles. Les géomètres utilisent rarement des courbes plus complexes que les arcs de cercle - si les personnes qui définissent les caractéristiques que nous cartographions n'utilisent pas elles-mêmes les courbes de Bézier, il n'y a pas beaucoup d'intérêt à dépenser un effort supplémentaire. Cependant, les autoroutes et les chemins de fer utilisent souvent des clothoïdes, bien que seuls les logiciels de CAO les supportent nativement. Ploppy 19h40, 2 octobre 2011 (BST)

Il existe deux variantes de mise en œuvre :

• le point de contrôle sera au centre du cercle - plus facile à calculer, moins bonne compatibilité "en amont
• le point de contrôle sera un point sur l'arc - plus complexe pour les logiciels qui calculent l'arc de cercle, mais plus facile à manipuler pour l'utilisateur, il y a une certaine rétrocompatibilité - le logiciel 0.6 ignorerait le tag type="circle" et obtiendrait juste une ligne beaucoup plus irrégulière (le point de contrôle se trouve sur le cercle), bien qu'à l'endroit correct.

ISO 19107 et GML utilisent la seconde représentation. Ploppy 19h40, 2 octobre 2011 (BST)

Dans les deux cas, le logiciel peut calculer exactement l'arc de cercle (sauf pour les données non valables, comme deux des points ayant la même position)

Bézier curves

Les points de contrôle de Courbes de Bézier peuvent être stockés de la même manière. Exemple de l'arc "quadratique" le plus couramment utilisé (deux points de contrôle) :

<voie ...>
 <nd ref="A" />
 <nd ref="B" type="bezier" />
 <nd ref="C" type="bezier" />
 <nd ref="D" />
</way>

Cette notaton peut traiter toutes les courbes de Bézier d'ordre inférieur ou supérieur. Exemple d'un arc "cubique" (un point de contrôle) :

<voie ...>
 <nd ref="A" />
 <nd ref="B" type="bezier" />
 <nd ref="C" />
</way>

Exemple d'un arc "quartique" (trois points de contrôle) :

<voie ...>
 <nd ref="A" />
 <nd ref="B" type="bezier" />
 <nd ref="C" type="bezier" />
 <nd ref="D" type="bezier" />
 <nd ref="E" />
</way>

Il gère également une situation particulière dans laquelle un arc n'a qu'un seul point de contrôle à une extrémité et l'autre extrémité n'a pas de point de contrôle séparé. Dans ce cas, l'autre point de contrôle est le même nœud d'extrémité :

<way ...>
 <nd ref="A" />
 <nd ref="B" type="bezier" />
 <nd ref="C" type="bezier" />
 <nd ref="C" />
</way>

Cette notation est rétrocompatible avec la version 0.6 de l'API, comme le point de cercle.

Je pense que la prise en charge des arcs (cercle, Bézier, clothoïdes) pourrait améliorer la qualité des cartes produites à partir des données OSM. Les routes, surtout en montagne, ont plus d'arcs que de lignes droites.

Afin de créer une carte imprimée à grande échelle de haute qualité à partir des données OSM, les polylignes devraient être converties en arcs. Une telle conversion n'est pas triviale car les données ne contiennent pas d'informations sur les segments qui sont réellement droits et ceux qui sont des arcs. C'est pourquoi la conversion automatique des polylignes en arcs échoue souvent.

Lorsque je surveille une route dans les montagnes sous des feuilles où la route n'est pas visible sur les images aériennes et où la réception GPS est également mauvaise, je marque les points où la partie droite se termine et où un arc commence. Je marque également les points d'inflexion où les arcs tournant à gauche se transforment en arcs tournant à droite. Cela m'aide à dessiner une forme plus précise de la route.

Les informations sur les arcs et les lignes droites sont perdues parce que je ne peux que placer des nœuds dans le chemin, mais je ne peux pas les marquer comme des points d'inflexion ou de passage à un arc droit. Placer une balise sur le nœud est ambigu si le nœud fait partie de plusieurs voies. Les intersections se trouvent souvent aux points d'inflexion.

Lorsque je trace une route qui comporte de nombreux petits arcs, j'utilise au moins 3 points entre les points d'inflexion. En utilisant des arcs de Bézier cubiques, un seul nœud suffirait pour décrire l'arc entier au lieu de 3 (ou plus). Cela permettrait d'économiser de l'espace de stockage, tandis que la qualité de la sortie serait bien meilleure. (Kolesár Mars 2016)

Conserver l'histoire à la scission d'un élément

Il arrive souvent qu'une voie soit divisée en deux ou plusieurs parties pour pouvoir appliquer différentes valeurs, par exemple pour la vitesse maximale ou la surface, aux différentes parties - ou même pour ajouter des parties de la voie entière à une relation seulement. Actuellement, cela est mis en œuvre de la manière suivante :

• supprimer les nœuds d'une partie du chemin
• créer un nouvel objet de cheminement contenant ces nœuds
• télécharger ça

Le problème avec cet algorithme est que la nouvelle voie commence avec la version 1 ; l'histoire de l'autre voie n'est plus liée à celle-ci.

Le problème devient évident à l'heure actuelle dans le cadre de la discussion sur la licence en ce qui concerne "quelles méthodes sont modifiées par ODBL/CC-BY-SA/PD uniquement", etc. et il pourrait y avoir d'autres problèmes également ; par exemple, l'étiquette source, qui mentionne la source des données, doit être supprimée lorsqu'un nouveau jeu de modifications applique d'autres sources à l'objet ; mais il devrait être possible de trouver chaque objet modifié à tout moment avec une source particulière. Pour y parvenir, un historique ininterrompu serait une bonne chose Jongleur. 08:44, 16 novembre 2010 (UTC)

Cela semble être la même chose que #Une histoire plus intelligente. (plus récent). --Aseerel4c26 ([[Discours de l'utilisateur:Aseerel4c26|talk]) 17:25, 11 février 2015 (UTC)

Faire des points d'intérêt en une seule fois

Pour l'instant, les points d'intérêt peuvent être cartographiés soit sous forme de points, soit sous forme de voies, ce qui rend la vie plus difficile aux utilisateurs de la base de données. Si les points deviennent des voies avec un seul nœud, ils peuvent être convertis en voies complètes car ils sont cartographiés de manière plus approfondie et nous pouvons nous débarrasser des concepts d'étiquettes sur les nœuds et de nœuds membres de relations.

Plus de vérification des erreurs intrinsèques?

Actuellement, l'API accepte parfaitement les chemins constitués d'un seul nœud et les chemins comportant plusieurs nœuds consécutifs (on sait que le Potlatch fait ce genre de choses). xybot corrige actuellement ces erreurs. Peut-être devrions-nous intégrer ces contrôles dans l'API ? --Une moitié 3544] 13:57, 30 décembre 2010 (UTC)

Une façon d'obtenir des relations orphelines et de représenter plus correctement les informations sous forme d'arbre

Il n'y a pas de bonne façon dans l'OSM de représenter l'information en forme d'arbre de manière simple, sans se baser sur des relations. Vous devez alors utiliser de multiples relations parents/enfants pour représenter ces relations. Si une relation de cette chaîne est orpheline, par exemple si elle n'a pas d'objet membre et n'est plus membre d'une autre relation, il n'y a aucun moyen de la récupérer facilement si vous ne connaissez pas l'identifiant de la relation. Une bonne façon de représenter les informations de type arbre est nécessaire, par exemple pour la relation stop_area, route et route master de public_transport=*. Le même problème se pose, par exemple, pour les établissements de soins de santé. Par exemple, un hôpital tel que la Charité de Berlin possède plusieurs départements répartis dans différentes banlieues. Dans ces localités, chaque bâtiment peut contenir une autre spécialité médicale et peut-être que quelqu'un établira un plan des chambres à l'intérieur à l'avenir. Une structure de données arborescente ou quelques extensions de relais permettraient également de résoudre le problème de l'utilisation abusive de la clé pour représenter la relation entre les objets et les enfants, comme dans

key:subkey_of_key:property_key_for_the_subkey=value

. --Fabi2 21h40, 30 décembre 2010 (UTC)

Commentaire additionnel aux balises de style d'arbre

Il existe de nombreuses balises de style d'arbre implicites telles que :

• highway=service + service=*
• {type=transport_public + {transport_public=*
• {amenity=parking + {parking=*

Le problème est qu'à mesure que l'on ajoute des propriétés à un objet "map", il devient de plus en plus difficile de spécifier à quelle caractéristique d'un objet "map" appartient une propriété (qui se chevauche). Un exemple simple : une université est-elle située sur un nœud ou dans le même bâtiment amenity=université ou {amenity=hôpital ? Et si l'hôpital est {fauteuil roulant=* et l'université uniquement {{fauteuil roulant=* ? Oui, jusqu'à présent, vous verrez alors quelque chose comme {hospital:wheelchair=yes et {{university:wheelchair=limited, alors que les candidatures ne chercheront que {wheelchair=*.

Jusqu'à présent, la seule solution propre est d'utiliser des relations pour ce genre de marquage, mais je ne pense pas que les relations n'étaient pas destinées à ce genre d'abus.

Le problème est que chaque tag peut être théoriquement combiné avec tous les autres tags et que tôt ou tard, il le sera aussi. Le tag A n'a aucun rapport avec le tag B, mais voici ce à quoi un cartographe s'attendrait s'il utilisait des tags comme power=* + {power:*=* et autres. --Fabi2 21h15, 11 avril 2011 (BST)

"Quarantaine"

Que diriez-vous de permettre aux utilisateurs de marquer une certaine région comme étant "en quarantaine" ou quelque chose dans cet esprit ? Lorsque vous effectuez des changements à grande échelle dans une région, comme par exemple une importation ou la préparation d'un nettoyage de changements antérieurs qui ont mal tourné, vous ne voulez pas que d'autres utilisateurs interfèrent. La "quarantaine" devrait

• "pas" interdit aux autres utilisateurs d'éditer, mais oblige seulement l'éditeur à afficher un avertissement, y compris un texte libre de l'utilisateur qui émet la quarantaine
• expire automatiquement, par exemple après 24h, afin que les gens ne puissent pas bloquer leur zone d'habitation pour toujours
• ne sont autorisés que pour les régions dans une certaine mesure
• peut-être pas disponible pour tous les utilisateurs, mais seulement sur demande (si l'utilisateur a suffisamment d'expérience, la fonction peut être activée pour lui, par exemple par le DWG ou un administrateur)

--Oli-Wan 10h43, 13 janvier 2011 (UTC)

Se débarrasser de l'API

Supprimez les appels API de lecture de données du serveur de base de données faisant de la planète et diffère minutieusement sa seule sortie directe. Les éditeurs et toute autre personne ayant besoin d'une interface de type API utilisent Xapi, OWL et d'autres services axés sur la planète.

Schéma de données simple

Étendre le schéma de données pour représenter directement les structures prévues au lieu de les construire de différentes manières à partir de "simples" parties. L'ensemble actuel de nœuds, de voies et de relations est censé être simple, mais il devient très difficile à comprendre lorsqu'on essaie de décrire des données plus complexes. Les moyens de les représenter directement font défaut, si bien que les gens construisent des solutions de contournement de plus en plus difficiles. Celles-ci sont très difficiles à comprendre pour les cartographes de tous les jours et presque impossibles à maintenir.

Exemples de complexité inutile :

• utiliser un moyen quand vous voulez dire "zone". Le contournement est une balise "area=yes" qui a causé beaucoup de confusion si et quand elle est nécessaire. Problème au niveau de la nuisance.
• Polygones/Multipolygones/Advanced Multipolygons : Trois concepts de plus en plus difficiles à décrire la même chose : une zone.
  • Polygone normal : La manière décrit une zone, la manière est l'objet principal
  • Multipolygone : La manière décrit une zone, d'autres manières sont associées comme des trous avec une relation. L'élément principal est toujours le chemin. Plus difficile à comprendre, risque d'erreur si vous manquez la relation
  • Multipolygone avancé : La relation décrit une zone, les voies font partie des lignes extérieures et intérieures. La relation est maintenant l'objet principal, jouant le même rôle qu'un objet multipolygone dans d'autres schémas gemmétriques. Très difficile à comprendre. Pas de définition claire. Très sujet à l'erreur. Nécessite un travail important dans tous les logiciels de rendu de cartes.

Proposition :

Séparer les objets géométriques et logiques. Utiliser une représentation directe pour les objets géométriques au lieu de solutions de contournement complexes. Ne pas utiliser les mêmes objets à différents endroits d'une hiérarchie ayant des significations multiples. Par exemple

• Géométrie (pas de balises) :
  • <node>
  • <line>
• Objets (avec balises)
  • <poi> : a un ou plusieurs <nodes>
  • <way> : a un ou plusieurs <lines>

<zone> : a un ou plusieurs outer-<lignes>, zéro ou plusieurs hole-<lignes>

• Groupements et relations
  • <relation> : <tous les objets>

Meilleure gestion de l'approvisionnement (balise "source")

Nous savons que la source des données et la date de la source sont des informations fondamentales lorsque nous utilisons des sources externes (comme l'imagerie aérienne) et pas seulement les contributions locales de l'enquête. Ces informations seront de plus en plus importantes lorsque l'OSM aura atteint un certain niveau d'achèvement. Nous ne pouvons pas éviter cela, mais les sources externes peuvent être dépassées et il sera alors important à l'avenir d'afficher rapidement les sources et les dates des contributions existantes, non seulement la date des éditions mais aussi les dates des sources comme les données publiques ou l'imagerie aérienne. Sinon, nous ne pouvons pas éviter que les contributeurs de fauteuil supplantent les contributions plus anciennes relevées localement ou que les images aériennes récentes ou les données publiques soient meilleures que les très anciennes enquêtes.
La solution actuelle consiste à placer la source de la balise dans le Changeset ou dans chaque élément, ce qui est totalement facultatif. Mettre la source dans le "changeset" n'est pas parfait car un "changeset" peut regrouper différentes sources. Mettre le source dans tous les nouveaux éléments est douloureux pour les éditeurs et cela demande beaucoup de ressources. La prochaine API devrait permettre d'identifier et de regrouper facilement les sources, de les mettre en évidence dans le protocole (au moins au même niveau que le "commentaire") et de fournir aux éditeurs de l'OSM un moyen facile de récupérer et d'afficher les sources (et la date de la source) dans l'historique des éléments. --Pieren] 12:49, 8 avril 2011 (BST)

===Segments (au lieu de voies fragmentées) - Oui, une nouvelle primitive ! Les limitations de vitesse, les routes, les ponts et autres éléments de la route, ainsi que bien d'autres choses encore, nous obligent à nous séparer. Avec un niveau de détail plus élevé (voies de virage, parking latéral, ...), nous finirons par représenter les routes individuelles comme des centaines de chemins extrêmement courts. Le concept de segments faciliterait grandement l'ajout d'éléments routiers, l'établissement de relations et empêcherait les utilisateurs de fusionner des parties qui ne devraient pas l'être, ce qui réduirait considérablement le nombre de relations rompues (si vous avez déjà été dans les relations de routes, vous voyez maintenant ce que je veux dire, n'est-ce pas ?)

Qu'est-ce qu'un segment ?

Un segment est une partie d'une voie, désignée par l'ID de la voie plus les ID des nœuds de départ et d'arrivée. Il peut être marqué et ajouté aux relations comme un chemin. Il peut y avoir des segments parallèles et/ou qui se chevauchent dans une voie.

Pensez par exemple aux voies de virage et à la manière dont les restrictions de virage peuvent être mises en œuvre de manière élégante dans la voie.

Comment l'API traite-t-elle les segments ?

L'API doit juste s'assurer que les nœuds de départ et d'arrivée ou le chemin ne sont pas supprimés tant que des segments y font référence. C'est exactement le même mécanisme que pour les relations.

Je comprends tout à fait le dogme "pas de nouvelles primitives", mais regardez les énormes avantages !

--BorisC] 01:28, 20 janvier 2012 (UTC)

+1 - Je me suis dit que j'allais écrire la même proposition. Il y a un gros problème qui ne fait que s'aggraver lorsque nous cartographions avec plus de détails sur les chemins. Cela créera de petits fragments qui ne pourront pas être manipulés facilement... [User:Magol|Magol]]. 20:47, 27 janvier 2012 (UTC)

Il semble que [les segments https://wiki.openstreetmap.org/wiki/Glossary#S existaient] avant la version 0.5 et "ont été supprimés, pour simplifier le modèle de données". Je suis d'accord qu'un tel objectif a été atteint au prix d'une édition compliquée. J'ai écrit un [blog http://he-the-great.livejournal.com/48067.html] décrivant le même problème. -- [User:He the great|He the great]] ([[Parole d'utilisateur:He the great|talk]) 06:04, 10 août 2013 (UTC)

: Il semble que les anciens segments n'aient pas été la pierre angulaire d'un chemin, segments non dirigés. -- Il est le grand ([[Parole d'utilisateur:Il est le grand [talk]]) 16:07, 10 août 2013 (UTC)

On peut voir cela comme une variante particulière des relations. Les relations générales ont une liste de tous leurs membres, tandis que le segment n'a qu'un membre de départ et un membre de fin.

Une alternative aux segments pour résoudre le problème des routes séparées est que l'API vous permet de mettre des balises sur des parties de route. Aujourd'hui, vous pouvez placer des balises sur les nœuds d'un chemin, mais pas sur un sous-ensemble du chemin. Si vous pouviez apposer des balises sur des sous-ensembles d'un chemin, la nécessité de diviser les routes disparaîtrait. Si vous voulez, par exemple, marquer un pont sur une longue route, vous n'avez pas besoin de diviser la route. Vous ne marquez que le nœud de départ et le nœud d'arrivée et vous définissez bridge=yes.

--Magol] ([[Parole d'utilisateur:Magol|talk]) 22:22, 18 octobre 2013 (UTC)

Route primitive

Tenter de cartographier les itinéraires des bus est un processus assez complexe, qui nécessite de diviser les trajets en plusieurs parties pour pouvoir se référer uniquement aux parties de la route que le bus utilise réellement. Il serait utile que, comme pour la proposition de segment ci-dessus, nous puissions avoir une primitive spécifique aux itinéraires. Comme d'autres primitives, elle pourrait être étiquetée et contiendrait une liste ordonnée de voies, ainsi que le nœud de départ et le nœud d'arrivée que cet itinéraire utilise.

<route id="123">
  <tag k="name" v="Bus route 66" />
  <segment ref="456" start="78" end="90" />
  <segment ref="457" start="90" end="150" />
  <segment ref="560" start="150" end="654" />
</route>

L'API garantirait que la route est continue, que chaque segment partage un nœud de connexion avec le segment suivant.

Utilisation de lat/lon comme id de nœud

Trop d'espace est actuellement gaspillé sur des nœuds non étiquetés. Étant essentiellement une paire lat/lon, ces nœuds stockent beaucoup d'informations supplémentaires et nécessitent un niveau d'indirection pour, par exemple, rassembler les nœuds pour trouver un moyen. Que se passerait-il si nous utilisions lat/lon au lieu de l'identifiant du nœud dans ce cas ? Avec notre résolution actuelle des coordonnées, lat+lon prend 63 bits, ce qui correspond à un ID de nœud de 64 bits.

Avantages :

• Supprime une indirection
• supprime les données de nœuds supplémentaires
• déplace l'histoire du changement d'une forme de chemin sur un chemin lui-même, là où il appartient vraiment

Contre :

• ne soutient pas l'augmentation transparente de la résolution lat/lot
• rend plus difficile le maintien de la cohérence des données, par exemple il est plus probable qu'un littoral ou des rues connectées soient déconnectés

Avec l'aide supplémentaire des éditeurs et de l'API (changements atomiques), cela pourrait ne pas être un problème Une variante hybride (nœuds à part entière pour les nœuds marqués et les nœuds utilisés de multiples façons, et latlon dégradé pour les autres nœuds) peut être envisagée

({chnav pense :)

Votez pour : pouce :

• rend le traitement des données beaucoup plus facile et moins gourmand en ressources, aucun tableau cartographié n'est nécessaire du côté client ;

Ayant utilisé 63 bits de 64, nous pouvons utiliser un bit comme drapeau "connected_node", puis utiliser une branche de traitement spéciale pour ces nœuds dans l'éditeur.

Permettre le traitement des messages via l'API

Actuellement, il est possible de vérifier le nombre de messages non lus. Il serait préférable de permettre la réception, l'envoi, la suppression, le marquage comme lu/non lu via l'API Bulwersator. ([[Discours d'utilisateur:Bulwersator|talk]) 12:27, 2 novembre 2013 (UTC)

Tout est une relation

Nous devrions revenir à une géométrie basée sur des segments de l'API 0.4 et regrouper (*pas* catégoriser) les éléments de manière relationnelle. Par exemple, une relation Street pourrait avoir :

• son nom
• Son identification dans d'autres bases de données pour des références croisées (telles que WikiData)
• Sa "géométrie en fil de fer" pour le routage avec tous les segments (actuellement, les rues sont divisées en fonction des distinctions des tags tels que les voies, le stationnement, les transports publics, la catégorie, etc.)
• L'empreinte physique de la rue sur le sol...
• ...qui pourraient être divisés voie par voie
• Les bâtiments liés à la rue avec les numéros de bâtiments correspondants
• Les arbres liés à cette rue
• Les voies parallèles au cas où il y en aurait (par exemple, lorsqu'elle est divisée)

Il serait également plus souple d'avoir d'autres types de modèles tels que les itinéraires des transports publics : chaque usage ne prend que les segments qu'il veut sans se répartir arbitrairement.

Cela faciliterait le traitement de toutes les données relatives à une rue, ce qui est bien plus que ce que nous avons actuellement de manière simple. Par exemple, ce n'est pas l'avenue des Champs Élysées, ce n'est qu'une infime partie que Nominatim m'a retournée lorsque j'ai fait des recherches.

D'autre part, il faudrait retravailler beaucoup sur les rédacteurs car les relations sont actuellement parfois délicates à monter.

Uploads suspects modérés

Retenir les téléchargements identifiés comme un problème par un système de notation (par exemple, les suppressions en masse par les nouveaux comptes) jusqu'à ce qu'un autre mappeur les approuve.

Récupérer uniquement les données entre certaines dates de changement d'ids

Ajouter des paramètres à "GET /api/0.6/map" qui filtrent les versions d'objets qui ont été créées en dehors d'une plage de dates (ou d'id de changement) donnée. La sortie serait la même que pour l'appel existant, ou pourrait également inclure l'historique complet des objets téléchargés.

Cela simplifierait beaucoup la révision de l'historique.

4ème dimension

Inclure la date et l'heure ou les intervalles de date (les intervalles de temps sont inclus) dans les clés et les valeurs :

Exemple :

name=Avinguda Francesc Macià
name:1960=Avenida del General Yagüe
name:1939-1978_12_06_14_59=Avenida del General Yagüe

Le format sera aaaa_mm_jj_hh_mm.Les intervalles sont séparés par -

La date A.C. = sera une date négative comme vous pouvez le voir sur OHM Nous avons également besoin de quelques balises supplémentaires comme :

highway=historique
historical=roman_roads
construction_date=-118-400

Ce sera quelque chose comme ça :

construction_date=-118-400
highway=historique
name=Via Domitia
historical=roman_roads
source=Panneau d'information Pont Romain, Route du Brest, Carhaix-Plouguer

Et nous avons également besoin d'une clé pour exprimer les différentes structures de calendrier (aujourd'hui, l'OSM est très présent en Europe et aux États-Unis, avec une structure de date chrétienne, mais à l'avenir, qu'en sera-t-il des autres structures de calendrier) ?

calendar_structure=christian

Nous pouvons également inclure des décennies :

name:1960s=Avenida del General Yagüe

Cela ressemble à un tag et non à une API. Date_namespace la proposition couvre ceci. ([[Parole d'utilisateur:Jojo4u|talk]) 00:12, 30 septembre 2016 (UTC)

Champ géométrique de la dernière date modifiée

L'un des plus gros problèmes du modèle de données actuel est que nous ne pouvons pas savoir quand un élément a été modifié géométriquement. Voir https://2018.stateofthemap.org/slides/W019-Present_and_Future_of_the_OSM_data_model_from_the_Overpass_API_perspective.pdf

Il est suggéré d'ajouter un champ "dernier changement géométrique" qui serait mis à jour de manière récursive (par exemple, l'élément parent serait également mis à jour).

Dans le nœud, ce champ sera mis à jour si lon/lat a été modifié, ou lorsqu'il a été créé.

Dans Way, lorsqu'un de ses nœuds a été mis à jour géométriquement, si l'ordre des références de nœuds a été modifié, ou si une référence de nœud a été ajoutée ou retirée de la route.

En relation, c'est un peu délicat car nous ne savons pas quels membres sont des membres géométriques ou des membres logiques. Au moins, nous pouvons mettre à jour ce champ sur les mises à jour des membres de rôles/tags connus (par exemple multipolygone), ou simplement considérer le champ "dernier changement géométrique" de tous les membres. En outre, tout réordonnancement, ajout ou suppression de membres mettrait ce champ à jour.

Époque des coordonnées du nœud

Chaque nœud de l'OSM contient une date lat, lon et la dernière date modifiée, mais comme les lieux fixes sur le sol se déplacent en raison de la tectonique des plaques, lorsque je refais un relevé du même lieu sur le sol chaque année, mes coordonnées GPS WGS84 seront différentes à chaque fois.

C'est pourquoi chaque nœud doit éventuellement avoir une valeur d'époque qui est l'heure à laquelle les coordonnées ont été obtenues. Dans le cas des coordonnées GPS, ce serait le moment où l'observation a été faite (ce qui peut ne pas être le moment où le nœud a été téléchargé ou modifié). Dans le cas de l'imagerie aérienne, ce sera l'époque que l'imagerie aérienne utilise. --Aharvey ([[Parole d'utilisateur:Aharvey|talk]) 12:05, 26 juin 2020 (UTC)

Améliorer les caractéristiques existantes

Statut pendant les téléchargements différés

Voir osm-dev thread.

Diffs à grain fin

Les avantages : Avantages : Téléchargement plus rapide pour les personnes utilisant des connexions à faible bande passante ou à forte latence. Plus de simultanéité lors de l'édition d'éléments volumineux ou complexes. Problèmes : Problèmes : Plus de complexité sur le serveur et le client.

Le format de téléchargement diff actuel est OsmChange, dans lequel chaque élément à éditer doit être présent. Cela fonctionne très bien pour la réplication, car cela signifie que de nombreuses applications peuvent traiter les diffs de manière autonome et les appliquer ou les réappliquer à une source de données sans problème. Cependant, cela ne fonctionne pas aussi bien pour l'édition, car une petite édition vers une très grande voie ou relation nécessite un téléchargement important.

Une meilleure solution, mais plus complexe, consisterait à ne transmettre que les modifications des éléments dans le téléchargement des différences (ou ce que l'on pourrait appeler un téléchargement de "patch"). Par exemple, si la modification consiste à ajouter un nœud à une voie, il n'est pas nécessaire de transmettre tous les nœuds de la voie, mais seulement la nouvelle référence du nœud et sa position d'insertion. Cela permet alors un système de verrouillage plus souple, où il n'est pas nécessaire que le numéro de version téléchargé corresponde strictement à celui du serveur, mais seulement à celui du serveur sur l'élément modifié. Cela devrait permettre une édition plus collaborative, en particulier pour les relations très étendues comme les frontières administratives des pays, qui peuvent facilement être éditées indépendamment dans des zones géographiques diverses.

J'ai un prototype fonctionnel de certaines de ces fonctionnalités, mais il faut encore travailler pour affiner les détails et mettre en œuvre le reste des fonctionnalités. -- [User:Matt|Matt]] 14:32, 12 décembre 2009 (UTC)

+1 si elle s'ajoute aux modifications existantes --Skippern]. 18:48, 17 décembre 2009 (UTC)

Meilleure interrogation des jeux de données

Si vous cliquez sur l'onglet "Historique" de la page principale, vous obtenez une énorme liste de modifications avec une case de limite qui coupe votre zone. Ainsi, tous les changements de taille de la planète effectués par les robots et les humains négligents apparaissent dans chaque requête, même si rien n'a été modifié dans la zone demandée. La requête de changements ne doit renvoyer que les changements qui ont modifié la zone demandée.

+1--Robotnic] 14:43, 3 mars 2010 (UTC)

• Je suis d'accord. C'est l'un des premiers problèmes que j'ai remarqué en tant que nouveau venu, et c'est toujours une grande douleur. Tongro 11:00, 15 mai 2010 (UTC)
• Bonne idée, mais j'aimerais ajouter un détail : Même si quelque chose a changé à l'intérieur de la boîte englobante, il devrait être possible de faire en sorte que le sous-ensemble des changements se recoupe avec la boîte englobante. Le croquis mentionné ci-dessus traite de la question d'obtenir un avis sur un ensemble de changements qui n'ont PAS affecté la zone demandée. Il ne résout pas les rapports de changement du type "le changement a affecté votre zone ; amusez-vous à trouver le nœud unique à l'intérieur des 200 000 autres éléments". Donc : Donnez-moi les changements de l'ensemble de modifications X dans la boîte B, s'il vous plaît. --Jongleur 17:51, 11 octobre 2010 (BST)

Rendre l'interface web accessible

Atteindre la norme BIENE d'accessibilité web pour l'interface de téléchargement, la carte, l'exportation, etc.

Espérons qu'ils ont leurs critères d'évaluation en anglais quelque part, ou que quelqu'un trouve un critère plus ou aussi approprié en anglais.

: Bien sûr, http://en.wikipedia.org/wiki/Web_accessibility ! Un moyen facile de faire un test rapide est d'utiliser Lynx :-)

: ARIA et Section 508 est ce que vous recherchez réellement -- [User:Eliasp|Eliasp]]. 00:52, 24 mars 2012 (UTC)

Remplacer DELETE /api/0.6/[node,way,relation]/#id

L'API 0.6 exige qu'une demande de suppression inclue une entité avec un fragment XML décrivant l'objet à supprimer. Bien que la spécification HTTP ne soit pas absolument claire quant à savoir si les entités sont autorisées ou non dans les demandes de suppression, la plupart des bibliothèques clientes HTTP disponibles (du moins dans le monde Java) ne les prennent pas en charge :

• JOSM s'appuie sur la pile HTTP fournie par le SDK Java. Il ne peut pas envoyer une requête DELETE incluant une entité et il l'émule avec un téléchargement diff
• Le client HTTP 4 d'Apache ne supporte pas une entité dans une requête HttpDelete

En API 0,7

• ne supporte pas DELETE /api/0.7/[node,way,relation]/#id incluant une entité
• introduce DELETE /api/0.7/[node,way,relation]/#id/#version?changeset=changesetId
  • supprime l'objet dans le changset changesetId à condition que le changset existe, qu'il soit ouvert et qu'il appartienne à l'utilisateur qui soumet la demande de suppression
  • #version est la version objet à supprimer. Si #version < version actuelle sur le serveur, une erreur est répliquée
  • #id est l'identifiant de l'objet à supprimer. Comme d'habitude, une erreur est répondue si un objet avec cet id n'existe pas ou s'il est déjà supprimé

Ce client HTTP Java devrait être retravaillé pour un support HTTP adéquat. Ce n'est pas une question d'API. Elle comporte de nombreux bogues et utilise un comportement non conforme à la norme, tel que l'en-tête non standard Proxy-Connection : instaed de Connection :. Ce qui est amusant, c'est que dans JOSM, pour une simple requête GET, il n'envoie que parfois un en-tête Content-Length:- avec 0 comme valeur, ce qui bloque la connexion si vous êtes derrière un proxy Kerio Winroute Pro bogué. Ce bogue a été difficile à trouver dans JOSM, car la requête de capacités passe au travers (sans Content-Length :), alors que JOSM s'est accroché à la requête de fermeture. Il est donc préférable de le signaler aux développeurs d'OpenJDK/SunJDK, si vous souhaitez un support HTTP/WebDAV adéquat. Il y a maintenant un workaroud dans JOSM pour ce bogue, il enverra "\r\n" pour empêcher le blocage de Winroute. --Fabi2 23:23, 6 février 2011 (UTC)

Remplacer la sortie de la /demande de capacités

Dans l'API 0.7, les capacités doivent être des réponses sous forme de simples paires nom/valeur, comme ceci :

  <capacités>
     <nom de la capacité="min_version" value="0.6"/>
     <nom de la capacité="max_version" value="0.6"/>
     <capability name="max_area" value="0.25"/>
     <capability name="max_tracepoints_per_page" value="5000"/>
     <nom de la capacité="max_nodes_per_way" value="2000"/>
     <capability name="max_changeset_size" value="50000"/>
     <capability name="timeout" value="300"/>
  </capacités>

Notes :

• il s'agit d'une caractéristique mineure et cosmétique. Si elle est mise en œuvre, elle contribuerait à simplifier l'API.

Gubaer 16:57, 5 décembre 2010 (UTC)

Variante en lecture seule

Environ 2/3 des données compressées sont dues au nom d'utilisateur, à l'identifiant de l'utilisateur, à l'identifiant du jeu de modifications, à l'horodatage et à la version, bien qu'ils seront abandonnés à un moment donné pour la plupart des usages, y compris la cartographie et le routage. Ils sont essentiellement seulement le besoin de rééditer les données plus tard. D'autre part, la grande taille des données empêche de nombreux cas d'utilisation.

Il n'est pas toujours possible d'abandonner les données à un stade précoce et de réduire la taille des données, car certains clients font des vérifie si les méta-données sont présentes. Cela pourrait être corrigé par une variante en lecture seule : Si la lecture seule est signalée dans l'en-tête, les outils de traitement ne doivent pas vérifier la présence de métadonnées. --- Roland.olbricht 08:54, 22 Oct 2011 (UTC)

Pour la réédition, seul le numéro de version est essentiel, les méta-données restantes (changeset, timestamp, ID utilisateur, nom d'utilisateur) ne sont pas nécessaires. Je vous suggère de laisser les numéros de version dans le fichier et de supprimer les identifiants des changeset, les timestamps, les uids et les noms d'utilisateur. --Marqqs 12h40, 22 octobre 2011 (BST)

L'api n'est pas en lecture seule, elle est destinée à l'édition. Donc peut-être que toutes les réponses ne devraient pas avoir de changesetid/timestamp/user/uid à moins que cela ne soit demandé (par exemple pour l'appel à l'historique) Marc marc (talk]) 12:51, 7 mai 2020 (UTC)

Téléchargement GPX en pistes séparées

Actuellement, lorsque vous téléchargez des traces GPS depuis le serveur, vous obtenez la plupart des traces (publiques ?) en une seule trace GPX <trk>. See : https://api.openstreetmap.org/api/0.6/trackpoints?bbox=3.1491280,45.8053798,3.1565094,45.8090295&page=0 Il serait plus utile pour les traitements automatisés (comme le moyennage) de les avoir séparés en plusieurs pistes <trk> à l'intérieur d'un même fichier GPX ou au moins en plusieurs segments de piste <trkseg> à l'intérieur d'une piste. --[Utilisateur:Eric S|Eric S 12:40, 6 novembre 2011 (UTC)

Améliorer les demandes d'historique

La seule façon d'obtenir des informations historiques sur une primitive est de demander une histoire complète via "/history". Cela peut prendre un certain temps avec les primitifs ayant une longue histoire. Cependant, tous les utilisateurs ne veulent pas toujours un historique complet, et certaines déclarations pourraient permettre d'obtenir un historique partiel pour accélérer les délais de traitement, lorsque tout n'est pas souhaité.

• '/short-history : permet d'obtenir uniquement l'historique des informations sur les métadonnées (version et horodatage). Cela peut être utile lorsqu'un utilisateur veut récupérer un objet à un moment précis, mais ne connaît pas son numéro de version. Actuellement, nous devons traiter tout l'historique pour trouver la bonne version. Au lieu de cela, nous pourrions appeler l'historique court pour ne récupérer que le numéro de version, puis appeler la "/#version" que nous voulons.
• /partial-history?min=A&max=B' : Obtenir uniquement des informations sur l'historique entre la version A et la version B ou entre le temps T1 et T2.

--Don-vip 16:39, 28 décembre 2011 (UTC)

Suppression des caractéristiques

supprimer /relation/id/full call

La possibilité de télécharger une relation et tous ses membres permet à de nombreux cartographes de créer des relations autrement inutiles ("tous les bancs de parc de Munich"), juste pour pouvoir télécharger plus facilement leur jeu de données sur les animaux. Il faut que cela cesse - laissons tomber l'appel /relation/id/full. -- [Utilisateur:Frederik Ramm|Frederik Ramm]] 22h59, 12 octobre 2010 (BST)

Je pense que ce n'est plus un problème, car de nos jours, les gens utilisent généralement l'API Overpass pour obtenir "tous les bancs de parc de Munich". 08:29, 22 avril 2019 (UTC)

Simplifier l'API lorsque c'est possible

Il est possible de télécharger des objets en diff ou individuellement. Pour autant que je sache, cela est conservé pour des raisons historiques. Chaque fonctionnalité de l'API doit être examinée pour être supprimée, sauf en cas d'absolue nécessité.

De plus, les informations contenues dans une requête doivent être spécifiées une fois. Dans certains cas, comme le téléchargement vers un ensemble de modifications, l'ID de l'ensemble de modifications est spécifié dans l'URL et dans le diff lui-même. 11:58, 25 octobre 2010 (BST)

Prevenir les "grosses" modifications=

Les "grands" Changesets signifient généralement qu'un cartographe de fauteuil essaie de changer le monde pour correspondre à leur compréhension de celui-ci. Empêcher la soumission de ces modifications obligerait le cartographe à les répartir géographiquement, ce qui permettrait aux cartographes qui soumettent des modifications basées sur le monde extérieur de savoir plus facilement quand une modification affecte un élément qu'ils ont ajouté.

Une alternative (si cela semble un peu drastique) pourrait être d'empêcher les modifications supérieures à une certaine taille par les nouveaux utilisateurs (quelle que soit la définition de "nouveau"). Les utilisateurs devraient "gagner" le droit de faire des dégâts de plus en plus importants.

Les modifications affectant un élément OSM géographiquement important (par exemple, une relation importante) seraient toujours autorisées. - SomeoneoneElse 17:36, 11 mars 2011 (UTC)

Qu'est-ce qui est "grand" ici ? S'agit-il de la surface ou du nombre d'objets touchés ? Dans les deux cas, une telle limitation rendrait les réparations et les nettoyages à grande échelle plus difficiles à réaliser et plus difficiles à annuler (si une erreur est trouvée après la modification des données) s'ils doivent être divisés en plus petits ensembles de modifications. Cependant, il peut être utile de ne limiter que les nouveaux utilisateurs (davantage pour le cas du "nombre d'objets", par exemple en déplaçant une grande partie des données vers une image satellite non alignée). - AMDmi3 23:56, 27 juin 2012 (BST)

Refuser les relations vides

Il y a des tonnes de relations sans aucun membre dans la base de données. La plupart d'entre elles semblent avoir été créées par accident. Celles qui ont été ajoutées intentionnellement sont dangereusement proches de tomber sous [Les relations ne sont pas des catégories] et il n'y aurait pas grand chose à perdre, si elles disparaissaient. L'API devrait donc refuser d'accepter des relations vides. Lonvia 18:05, 20 juillet 2011 (BST)

Même si les relations vides peuvent être des accidents la plupart du temps maintenant, elles peuvent aussi être utilisées pour exprimer plus correctement des choses comme par exemple highway=service. + service=driveway, qui signifie en fait autoroute-->service-->driveway. Chaque balise est indépendante et il n'y a rien dans l'API pour spécifier quelles balises appartiennent les unes aux autres. Cela conduit également à des choses comme key:subkey:subsubkey=value ou à l'utilisation de " ;" où une structure clé/balise de style arborescent serait préférable pour représenter ces choses. J'espère que ce problème sera résolu dans l'API 0.7, car pour l'instant les relations vides sont la seule façon de construire de tels arbres pour éviter l'utilisation de " ;" dans les valeurs (par exemple pour cuisine=*). --Fabi2 00:46, 25 juillet 2011 (BST)

Actuellement, il y a environ 40'000 relations sans membre, et 3156 relations sans membre + tags. Il est possible d'effectuer une recherche via Overpass. Mmd ([[Parole d'utilisateur:Mmd|talk]) 13:07, 15 avril 2018 (UTC)

Interdire les balises vierges

Pour l'instant, vous pouvez créer une balise dont la valeur est une chaîne vide. Les éditeurs et les consommateurs de données n'en sont pas très conscients et toutes les apparences dans la base de données semblent être des accidents ou le résultat de bogues d'éditeurs. Rien ne serait perdu en faisant de la création d'une telle balise une erreur et en signalant les balises existantes comme des clés non utilisées. Andrew ([[Parole d'utilisateur:Wynndale|talk]) 18:39, 21 octobre 2013 (UTC)

+1 drolbr

3D, ou 2,5D

Celui-ci est loin d'être parfait : il faut prévoir une coordonnée z. Soit en ajoutant des primitives 3D, soit en faisant des nœuds une primitive 2,5D et en travaillant dessus. Oui, cela rendra les utilisateurs de Potlatch fous dans les zones à forte densité. Oui, cela rendra fous les outils de validation. Mais, hé, cela permettra aux japonais de cartographier correctement ces horribles bâtiments à plusieurs niveaux avec des routes en dessous, et de se débarrasser de l'infâme balise level=. --Ivansanchez] 10:41, 2 février 2010 (UTC)

Triangles

OK, donc OSM a révolutionné le SIG en s'éloignant des points, des lignes et des polygones et en utilisant des nœuds et des chemins (et des segments - oh, le bon vieux temps).

Donc, "si" nous allons nous attaquer à la question des zones et des polygones, nous devrions aussi être innovants et ne pas être pris dans les mêmes pièges que les gens qui travaillent sur les SIG en 2D (armonisation des frontières, éclats, chevauchements, etc.). Après tout, nous sommes des informaticiens, pas des arcturistes, pour l'amour de $DEITY. Allons à l'essentiel. Allons à la primitive 2D la plus simple. Utilisons des triangles.

Pensez au monde comme à un grand maillage triangulaire (tous ceux qui ont déjà vu un modèle filaire en 3D le savent). Un triangle n'est pas une voie : ce ne sont que trois nœuds. Et il doit y avoir des livres sur les algorithmes permettant de vérifier la cohérence des maillages triangulaires et des trucs topologiques.

Ainsi, une "zone" est juste une relation de triangles. C'est facile. Un logiciel d'édition serait capable d'afficher tous les triangles, et de laisser l'utilisateur cliquer dessus pour les ajouter à la relation de surface, ou quelque chose comme ça. La vérification des zones à l'intérieur des zones devrait être très facile.

Je suis d'accord pour dire qu'une nouvelle primitive de données est un casse-tête pour les développeurs, mais cette idée de triangle pourrait valoir la peine d'être envisagée. --Ivansanchez 10:41, 2 février 2010 (UTC)

GPX upload API

Cette api est très bonne pour le téléchargement de formulaires. Pour le téléchargement automatique, ce n'est pas un gros problème mais ce serait plus facile avec quelque chose comme ça :

code format="xml" <toutes> <description>blabla</description> <peu importe>blabla</peu importe> <gpx xmlns="http:/ ...gpx ..."> </gpx> </toutes> [code]]

en plus du téléchargement de formulaires en plusieurs parties.

Actuellement, l'API exige que les points de suivi aient un horodatage. Cela n'est pas requis par la norme GPX GPX 1.1 waypoint type. Certaines personnes n'aiment pas télécharger des pistes avec des informations d'horodatage. Il y a de nombreuses discussions au sein de la communauté sur la manière de truquer ces valeurs. Certaines personnes publient même des scripts correspondants. Cela dégrade la qualité des données. D'autres personnes pourraient, pour cette raison, ne pas envisager de télécharger des traces du tout. Cela réduirait le nombre total de pistes téléchargées. Je ne vois aucune raison pour laquelle on voudrait avoir un horodatage à chaque point de suivi. Il devrait suffire de connaître l'âge d'une trace. On pourrait prendre la date de téléchargement comme première approximation de l'âge d'une piste. En outre, l'utilisateur peut être amené à préciser l'âge au cours du processus de téléchargement. Par conséquent, je suggère de rendre facultative la présence d'informations d'horodatage sur les points de suivi, mais d'exiger la spécification de l'âge de la piste dans son ensemble. Cela devrait augmenter la fiabilité des valeurs d'horodatage, au cas où elles seraient présentes. --Schlauchboot] 11h48, 20 mars 2012 (UTC)

: La documentation actuelle (v0.6) est manquante Documentation des messages d'erreur pour l'API de téléchargement GPX, veuillez l'inclure pour la v0.7 --Skippern]. ([[Conversation d'utilisateur:Skippern|talk]) 19:05, 27 mars 2016 (UTC)

Conserver le format XML

De nombreux programmeurs apprécient le nouveau format binaire. Selon eux, il augmenterait la vitesse des logiciels et réduirait les temps de téléchargement. Mais d'un autre côté, aucun cartographe ne serait capable de lire ses propres cartographies sans avoir besoin d'un logiciel osm spécial. Les formats binaires ne sont pas vraiment ouverts à l'utilisateur final, même s'ils sont bien documentés. Ils créent une certaine dépendance des utilisateurs à un logiciel spécial, mal connu des anciens jours de bureau. De nombreux cartographes n'aimeront pas cela. Le nouveau format peut convenir à certaines fins, mais n'abandonnez pas l'ancien, ni n'en créez un nouveau, compatible avec le format binaire et lisible par n'importe quel éditeur, qui comprend l'utf-8.

Problèmes non résolus

Certains problèmes n'ont pas encore trouvé de solution. Une solution doit être trouvée.

Le problème de la direction

Avec la plupart des éditeurs, il est très facile de changer accidentellement la direction d'une voie en un seul clic. Cela détruit toutes les informations qui en dépendent, comme par exemple la vitesse maximale : avance/retour (gauche/droite, ...) ou les relations comme les itinéraires. L'inversion est très difficile à observer et, dans de nombreux cas, uniquement pour ceux qui vérifient et comparent soigneusement le chemin dans la réalité. Ainsi, dans les régions rurales, le défaut pourrait survivre des années. Certains éditeurs, par exemple Potlatch, ne rendent pas cette destruction visible pour l'utilisateur qui fait marche arrière. Cela est tout simplement impossible car l'OSM n'a pas de jeu défini de balises et de relations. En outre, dans le cas de la cartographie des panneaux de signalisation (vitesse maximale, panneau de ville), il faut une direction pour ce nœud, ce qui n'est pas possible actuellement. L'API 0.7 devrait donc apporter une solution.

Il est possible que la direction d'une route soit donnée automatiquement au moment de la création et non par l'utilisateur, et qu'elle ne soit pas modifiable. Cela pourrait se faire en donnant une direction uniquement dans un rayon de 180 degrés entre le nœud de départ à l'ouest et le nœud d'arrivée à l'est au moment de la création. La direction d'une route pourrait alors être donnée par une balise avant/arrière. Cela permettrait au moins de résoudre le problème de la direction pour les voies mais pas pour les nœuds. Une solution plus récente doit être trouvée. -- Tirkon 07:14, 23 avril 2011 (BST)

Des relations détruites

Les relations peuvent être détruites en changeant de membres sans autre avis de l'éditeur et de l'utilisateur. Comme l'OSM n'a pas d'ensemble défini de balises et de relations, cela est tout simplement impossible. C'est-à-dire la division des voies parce que la fin ou l'arrêt d'une relation de voie est presque invisible dans un éditeur et force l'utilisateur à les rejoindre, s'il doit éditer autour du nœud de division. Cela pourrait en outre changer la direction de l'une des voies jointes, ce qui pose des problèmes avec les balises et les relations de direction (voir ci-dessus). Une nouvelle fonctionnalité de l'API pourrait éventuellement aider. -- Tirkon 07:14, 23 avril 2011 (BST)

Un ensemble de moyens

Avec l'API actuelle, le problème du faisceau de voies (c'est-à-dire les voies de virage à gauche/droite, les pistes cyclables/parking, le trottoir, la ligne centrale, etc.) n'a pas pu être résolu de manière satisfaisante, bien qu'un WikiProject Germany/Workshops/Linienbündelworkshop ait eu lieu. Une nouvelle fonctionnalité de l'API pourrait éventuellement aider. -- Tirkon 07:14, 23 avril 2011 (BST)

Transports publics

La cartographie des transports publics a une longue histoire dans l'OSM. Différentes solutions ont été développées. Deux ateliers ont eu lieu. Une liste de diffusion spéciale a été créée. Mais à chaque fois que des solutions ont été présentées, les gens ont eu du mal à s'y retrouver. Elles étaient trop complexes, difficiles à comprendre et ne répondaient pas à tous les besoins. Une fonction API ingénieuse pourrait peut-être les aider. -- Tirkon 07:14, 23 avril 2011 (BST)

Directions, relations détruites, faisceau de voies, transports publics

Il est possible que de nombreux détails problématiques aient le même noyau et puissent donc être résolus par une ingénieuse fonction API. -- Tirkon 07:14, 23 avril 2011 (BST)

Résolution de problèmes complexes (et faciles) par le bac à sable/terrain de jeu OSM

Contrairement à Wikipedia, nous n'avons ni common Sandbox ni de sandboxes appartenant aux utilisateurs (1 2) dans OSM. Cela nous empêche de trouver des solutions à des problèmes aussi complexes que ceux décrits ci-dessus - seuls ou en groupe. Le principe "Try And Error" n'est tout simplement pas possible sans nuire à la base de données originale. Une solution pourrait être une base de données différente d'une "mini-terre/planète". Cependant, le gros inconvénient est que tous les outils et applications OSM ne fonctionneront pas avec elle. Il pourrait être utile de réserver une partie "cachée" de la base de données normale à cette fin. Cela pourrait être par exemple à la latitude 0 à -1 Nord (remarquez le !!moins !! 1). L'API fournit cette zone imaginaire au lieu du 0 à +1 Sud réel tout en convertissant le 0 à -1 Nord en 0 à +1 Sud uniquement à ce moment-là, si l'utilisateur a préalablement défini un drapeau indépendant de l'application. Ainsi, la zone "cachée" apparaîtra dans chaque application dès que le drapeau sera activé.

Cela nous aide à trouver des solutions et à les tester dans chaque application comme cela est fait dans Wikipedia. Cela aiderait également les débutants à découvrir des constructions complexes comme par exemple les relations entre parents et enfants. Les parties réservées aux utilisateurs pourraient expliquer des exemples complexes pour les débutants. Cela n'est pas possible pour le moment car les exemples de la base de données réelle pourraient être modifiés entre-temps.

Si la zone cachée n'est pas possible telle que décrite pour une raison quelconque, il faut trouver une autre solution API qui fonctionne avec chaque application. -- Tirkon 08:07, 23 avril 2011 (BST)

Fait - Solutions déjà disponibles

API 0,6

Téléchargement de données compressées

En raison de la redondance du XML, il a un taux de compression très élevé, alors pourquoi ne pas envoyer et recevoir des données dans un fichier gzip ? Lors du téléchargement d'un tel fichier, les serveurs traitent les données et renvoient tous les conflits qui nécessitent un peu plus de travail (comme le font les JOSM, certains d'entre eux peuvent être résolus automatiquement).

Le serveur supporte déjà la compression HTTP. Pas besoin de fichiers gzip. -- Firefishy 09:14, 26 juillet 2010 (UTC)

Pour télécharger les modifications, voir https://github.com/openstreetmap/operations/issues/193 Mmd ([[Parole d'utilisateur:Mmd|talk]) 12:24, 15 avril 2018 (UTC)

une demande doit livrer tous les nœuds, voies, relations d'une bbox

Je pense qu'il est compliqué d'envoyer trois demandes pour obtenir des données sur les voies, les nœuds et les relations. Je veux pouvoir envoyer une demande pour une bbox et obtenir tous les éléments concernés dans un fichier xml. --Flaimo 12:04, 20 avril 2011 (BST)

Quelque chose que la /api/0.6/map ne fait pas ? Alv 07:43, 27 avril 2011 (BST)

Agnosticisme de format

L'API n'est pas vraiment très MVC - il n'y a qu'une seule vue, XML, et le code de sérialisation est actuellement dans les contrôleurs plutôt que dans la vue. Idéalement, les mêmes appels API devraient être disponibles via les vues XML, JSON, AMF (etc.). Il faudra peut-être réfléchir aux conséquences sur les performances de Rails.

Il existe un format json pour les données géographiques. Il s'appelle geojson. geojson ne donne pas toutes les possibilités du format OSM-XML. Avec geojson, il n'est pas possible de partager un nœud. --Robotnic 12:24, 3 juillet 2011 (BST)

Déplacement du XML, la sérialisation vers la vue est actuellement en cours. Mmd ([[Parole d'utilisateur:Mmd|talk]) 19:45, 21 avril 2019 (UTC)

Passage à la page wiki, génération XML/JSON via le constructeur, les autres parties du support JSON sont gérées dans la version Github.

Dépassement de l'API

Multipolygone bbox

Permet d'utiliser les relations frontalières comme bbox lors du téléchargement d'une zone. Cela permettra de ne télécharger qu'une certaine commune au lieu de faire plusieurs téléchargements (qui se chevauchent souvent) pour couvrir la même zone.

+1 de ma part ! --Lulu-Ann] 16:14, 16 décembre 2009 (UTC)
+1 de ma part ! -- [User:Bahnpirat|Bahnpirat]] 14:57, 17 mars 2010 (UTC)

Les polygones des relations ont encore des problèmes et en auront encore pendant longtemps. Voir ci-dessus à #Aires. Je suggère plutôt un appel de carte à télécharger à partir d'un polygone dont les coordonnées sont explicitement indiquées.

Ceci est possible avec Overpass API--Jojo4u] (talk) 23:43, 29 septembre 2016 (UTC)

Téléchargement de toutes les données à l'intérieur d'une relation (ou limite administrative)

Aujourd'hui, pour obtenir toutes les données à l'intérieur d'une relation dans un fichier map.osm, j'ai besoin de pgsql et d'osmose. Je serais heureux de pouvoir télécharger map.osm (dans l'onglet d'exportation du site) d'une relation, de la même manière que je le fais avec une BBox.

Comme la bbox Multipoligon ? --Skippern] 19:32, 17 décembre 2009 (UTC)

Ce n'est pas le travail de l'API (AKA WONTFIX). Un logiciel côté client (je pense à JOSM) peut aller chercher la relation, et calculer de nombreuses petites boîtes. JOSM peut déjà le faire pour de longues distances ou des traces GPX, donc des zones devraient être faisables. --Ivansanchez] 10:41, 2 février 2010 (UTC)

Déjà possible via le plugin miroir OSM + les requêtes de dépassement (bien que la convivialité puisse être améliorée comme toujours). --Sanderd17 ([[Parole d'utilisateur:Sanderd17|talk]) 16:16, 11 février 2015 (UTC)

Faciliter l'obtention d'un état complet des voies ou des relations à une date

Actuellement, les voies et les relations se réfèrent uniquement à leurs membres par leur identifiant, ce qui signifie que si un changement est effectué sur les membres de la voie ou de la relation, la voie ou la relation n'est pas modifiée. Ainsi, la voie ou la relation peut rester à la version 1 alors que de nombreux changements ont été effectués sur leurs membres. Je pense qu'il pourrait être intéressant d'avoir quelque chose comme

• GET /api/0.6/[ways|relations]/#id/full/#date (renvoie tous les membres de la relation dans l'état où ils se trouvaient à la date indiquée dans le paramètre)

Actuellement, j'effectue cela dans mon outil de surveillance en demandant l'historique de la façon/des relations pour obtenir l'état correspondant à la date et ensuite je demande l'historique de chaque membre pour obtenir l'état correspondant à la date ce qui fait beaucoup de demandes API. Je suppose que cette fonction devrait être plus facile d'accès -- [[Utilisateur:Quicky|quicky] 2:35, 3 Jan 2013 (UTC)

Peut être réalisé via l'API Overpass, voir http://overpass-turbo.eu/s/xTU Mmd ([[Parole d'utilisateur:Mmd|talk]) 12:19, 15 avril 2018 (UTC)

Recherche de tag en tant qu'élément de premier niveau

Xapi fournit une facette de recherche très puissante qui offrirait de grands avantages dans le cadre de l'API principale : la recherche de nœuds ou de balises. Il y a de nombreuses opérations intéressantes à effectuer sur "toutes les fontaines à eau dans cette boîte englobante", par exemple. La recherche par balises devrait permettre d'obtenir une boîte englobante beaucoup plus grande que toute autre opération, ou peut-être de prendre en charge une fonction de limitation/compensation (renvoyer les 1000 premières fontaines à boire... les 1000 suivantes... etc).

Le top n est supporté par l'API Overpass, mais il n'est pas (encore) possible de sauter le premier n Mmd. ([[Parole d'utilisateur:Mmd|talk]) 08:43, 22 avril 2019 (UTC)

Utilisation d'un polygone pour télécharger des données

Outre le téléchargement areas ou multipolygons, un ajout intéressant serait de télécharger tout ce qui se trouve à l'intérieur d'un polygone arbitraire.

Comme le prédicat bbox, mais étendu pour utiliser plus de points de bord : poly=[52.36,4.88,52.36,4.92,52.39,4.90] permettrait de télécharger un triangle au centre d'Amsterdam.

C'est déjà possible avec API de passage, voir guide de langue :

(
  (poly : "52.36 4.88 52.36 4.92 52.39 4.90") ;
  < ;
) ;
out meta ;

Faciliter le suivi des objets parents

Ajouter un ensemble d'appels API qui permettent à un éditeur de conserver une liste de tous les parents pour un certain objet :

• pour un noeud, avoir une liste de toutes les façons qui contiennent ce noeud
• pour tout objet, avoir une liste de toutes les relations de référence

C'est là que nous perdons actuellement le fil :

• GET /api/0.6/[node|way|relation]/#id (télécharger les objets individuels)
• GET /api/0.6/[nodes|ways|relations] (télécharger les membres manquants d'une relation)
• GET /api/0.6/relation/#id/full (télécharger tous les membres de la relation)
• GET /api/0.6/map?bbox=... (pour les nœuds en dehors de la bbox et pour les relations parentales des relations qui ont des membres physiques à l'intérieur de la bbox)

(Il y a des appels pour obtenir explicitement les parents pour un objet individuel, mais cela provoquerait un trop grand trafic pour l'utiliser à chaque fois). -- Bk 07:13, 13 mai 2010 (UTC)

Les opérations de récursivité de l'API des passages supérieurs peuvent être utilisées à cette fin. Mmd ([[Parole d'utilisateur:Mmd|talk]) 08:52, 22 avril 2019 (UTC)

Support pour les requêtes de téléchargement comme addr:*=*

Support pour les requêtes de téléchargement comme addr:*=*, pour supporter les sous-tags.

Peut être fait avec API de dépassement--Jojo4u]. ([[Discussions d'utilisateurs:Jojo4u|talk]) 23:31, 29 septembre 2016 (UTC)

Requêtes SQL

En l'état actuel des choses, l'importation de la planète dans postgres implique de la convertir en xml, de télécharger des fichiers volumineux, d'analyser quelque 170 Go de xml par osmose et osm2pgsl pour arriver à une base de données qui ressemble à l'original, mais qui n'est pas la même que celui-ci. Et tout cela alors que nous pourrions simplement émettre une requête SQL et obtenir les données brutes dont nous avons besoin, sans aucune conversion. Cela serait particulièrement utile à ceux qui ont besoin de zones relativement vastes, mais pas du monde entier ou de toutes ses caractéristiques.

Il suffirait d'une carte de base hot standby avec un accès en lecture mondiale aux tables pertinentes, et elle remplacerait le master en cas de catastrophe, sans frais supplémentaires.

Je dirais que ce n'est plus nécessaire grâce à Overpass. -M!dgard] [ talk ] 10:37, 29 janvier 2018 (UTC)

Wikibase

Classes

La base de données contient peu d'informations sur la sémantique. Par conséquent, il existe des dizaines de façons de baliser une piste cyclable. La construction d'une feuille de style de rendu devient très compliquée. De plus, le logiciel pour éditer la carte doit avoir beaucoup de connaissances implicites. Et il y a beaucoup de contradictions et d'incohérences entre les différentes définitions, dans le wiki ou dans l'utilisation dans différentes parties du monde. Prenons par exemple la notion Trunk : au Royaume-Uni, elle fait référence à la connectivité de la route et à son financement. En dehors du Royaume-Uni, par exemple en Allemagne, la notion est utilisée pour les routes avec ce panneau de signalisation. En Allemagne, les transports publics sont organisés au sein de transport associations, alors qu'ils existent rarement ailleurs.

L'idée est d'avoir une déclaration dans la base de données pour la sémantique d'un tag dans une certaine région :

<classe> <pivot k="highway" v="almost_motorway"/> <desc lang="en"> Utilisez cette valeur pour les routes avec panneau de signalisation http://upload.wikimedia.org/wikipedia/commons/c/c6/Zeichen_331.svg à l'intérieur de l'Allemagne. </desc> <desc lang="de"> Kraftfahrstraße bzw. Kraftfahrzeugstraße. </desc> <Polygone limitrophe> (Frontières rugueuses de l'Allemagne) </bounding-polygon> <implique k="highway" v="trunk"/> <implique k="piétons" v="no"/> <implique k="bicycles" v="no"/> </classe> <classe> <pivot k="highway" v="almost_motorway"/> <desc lang="en"> Utilisez cette valeur pour les routes avec panneau de signalisation http://upload.wikimedia.org/wikipedia/commons/c/c6/Zeichen_331.svg aux Pays-Bas. </desc> <Polygone limitrophe> (Frontières rugueuses des Pays-Bas) </bounding-polygon> <implique k="highway" v="trunk"/> <implique k="maxspeed" v="100"/> <implique k="piétons" v="no"/> <implique k="bicycles" v="no"/> </classe>

Ainsi, les agents d'édition peuvent simplement proposer des classes qui s'appliquent à la région éditée et n'ont pas besoin d'avoir leur propre sémantique. Ils peuvent même proposer des suggestions cohérentes pour les valeurs des balises. Des éléments tels que les limites de vitesse par pays peuvent facilement être intégrés. Les rendus n'ont plus besoin de se soucier des différences subtiles. Les balises sur les nœuds, les voies et les relations peuvent être normalisées selon des règles simples tout en analysant. Ainsi, les feuilles de style peuvent devenir beaucoup plus simples.

Ce type d'information peut aujourd'hui être trouvé dans la Wikibase : https://wiki.openstreetmap.org/wiki/Item:Q4980 Mmd (talk]) 19:38, 21 avril 2019 (UTC)

Hors de portée de l'API d'édition OSM

compression de la géométrie

Si quelqu'un veut montrer l'autoroute européenne sur une (petite) carte, il n'est pas facile pour le moment d'obtenir les données vectorielles. Il devrait y avoir une compression avec perte qui pourrait être mise en œuvre par étapes : # Prendre seulement chaque seconde/quatrième/huit/... nœud d'une voie. La compression maximale serait le nœud de début et de fin. # Ignorer les nœuds trop proches les uns des autres. # Trouver une façon plus mathématique de décrire la voie. Une spline pourrait approcher de nombreux points. # Jouez avec le niveau de zoom, le taux de compression, la précision Pourquoi faire cela ? Une bonne compression permettrait d'utiliser la carte avec une base de données hors ligne. Les gens aimeraient avoir des cartes hors ligne sur un smartphone. Des courbes : svg [http://www.w3.org/TR/SVG/paths.html#PathDataCurveCommands], canvas [http://canvas.quaese.de/index.php?doc_id=27&nav=6,38] -- [User:Robotnic|Robotnic 09:26, 4 juillet 2011 (BST)

Vous pouvez déjà le faire en traitant vous-même les données du fichier planète de l'OSM avant de les donner à vos utilisateurs. Certaines personnes le font déjà. GPSBabel a déjà la capacité de faire ce que vous voulez pour les traces GPD, je suis sûr que le même algorithme ou des algorithmes similaires pourraient être appliqués aux données OSM. Smsm1 09:58, 22 août 2012 (BST)

Prouver des données avec une compression géométrique n'est pas le but d'un OSM édition. API, celle-ci devrait être fournie par un service externe. Mmd ([[Parole d'utilisateur:Mmd|talk]) 08:27, 22 avril 2019 (UTC)

Régions géographiques

Il est nécessaire de modéliser les régions géographiques (chaînes de montagnes, vallées, plaines, plateaux, ...) qui pourraient ne pas être reliées aux frontières administratives (la vallée du Rhin supérieur appartient à l'Allemagne et à la France). Ces régions pourraient avoir un ordre hiérarchique en termes de régions et de sous-régions (les Alpes sont constituées de plusieurs étendues montagneuses, chacune ayant son propre nom). voir aussi Relations/Proposition/Région

C'est une pure question de marquage. Mmd ([[Parole d'utilisateur:Mmd|talk]) 22:37, 9 janvier 2020 (UTC)

Propositions non réalisables

Objets immuables

Au lieu d'avoir des révisions d'objets, ayez des objets immuables et laissez-les pointer vers leurs propres ancêtres. Cela permettra de résoudre le problème de l'origine en divisant et en fusionnant les objets. Cela permettra également des révisions plus faciles. Lorsqu'un objet est modifié, il sera invalidé et une nouvelle copie sera créée avec de nouveaux attributs.

Cela pose de sérieux problèmes en cascadant les mises à jour, par exemple parce qu'une modification d'un nœud invaliderait toute façon et relation utilisant ce nœud (parce qu'elles pointent sur un ID d'objet qui n'existe plus après avoir changé le nœud). De même, les modifications de la voie invalideraient les relations et éventuellement d'autres relations.

Meilleure précision

Actuellement, la base de données stocke les données sous forme d'entiers de 32 bits. Et c'est très bien, car cela fonctionne tout simplement(tm).

Cependant, la méthode est tellement "dump" (il suffit de multiplier les coordonnées epsg:4326 par 10 millions) qu'il y a une grande perte de précision dans le processus : la précision maximale que l'OSM peut atteindre est d'environ 2 centimètres. Et il y a beaucoup d'espace perdu (par exemple de -217 à -90 et de +90 à +213 de latitude).

2 centimètres peuvent sembler peu, mais certaines applications (par exemple les cartes cadastrales) doivent être précises à moins d'un centimètre près. Il devrait être possible d'intégrer à la fois le latin et le long dans un champ de 64 bits, d'une manière qui ne soit pas complètement nulle et qui utilise mieux l'espace d'adresse disponible. Hélas, c'est un problème de si faible niveau qui ne peut être résolu qu'au niveau de l'API et de la base de données. --Ivansanchez] 10:41, 2 février 2010 (UTC)

Je ne pense pas que vous puissiez gagner beaucoup. La longitude prend des valeurs comprises entre -Lon_Max et +Lon_Max, où Lon_Max est Pi. La latitude prend des valeurs comprises entre -Lat_Max et +Lat_Max, où Lat_Max = Pi/2. Si vous faites correspondre ces intervalles à [-Int_MaxValue, +Int_MaxValue], vous obtenez Lon_IntValue = Lon * (Int_MaxValue / Lon_Max) et Lat_IntValue = Lat * (Int_MaxValue / Lat_Max). Par conséquent, la résolution serait Delta_Lon_IntValue = 1 = Delta_Lon * (Int_MaxValue / Lon_Max) et Delta_Lat_IntValue = 1 = Delta_Lat * (Int_MaxValue / Lat_Max). La résolution sur le méridien est alors Delta_Y = R * Delta_Lat = R * ( Lat_Max / Int_MaxValue ), où R est le rayon de la terre. La résolution sur les parallèles dépend de la latitude. A l'équateur, c'est Delta_X = R * ( Lon_Max / Int_MaxValue ). Pour les entiers de 32 bits, on a Int_MaxValue = 2^31. Par conséquent, la résolution sur le méridien est d'environ 4,7 mm. À l'équateur, la résolution est d'environ 9,3 mm. À environ 60 degrés de l'équateur, la résolution est d'environ 4,7 mm dans les deux directions. Cette résolution est proche de la solution actuelle, qui utilise un facteur de 10 millions pour la latitude et la longitude en degrés. Cela donne un facteur de 180 * 10 millions par rapport à 2^31. Par conséquent, l'amélioration par rapport à l'équateur serait de 2^31 contre 180 * 10 millions, soit une amélioration de seulement 20%. Au méridien, en revanche, on pourrait améliorer la résolution d'un facteur d'environ 2. Notez que ce n'est qu'un bit, que vous ne pouvez pas couper en deux. Je ne pense pas que l'on puisse obtenir mieux que cela. --Schlauchboot] 20:04, 20 mars 2012 (UTC)

L'augmentation de la précision n'est-elle pas plutôt (en fait totalement) inutile, étant donné que les changements par rapport à une année de dérive des continents sont déjà plus importants que toute amélioration de la précision que nous pourrions obtenir ? Si un changement devait être envisagé, ne serait-il pas beaucoup plus logique de passer à des systèmes de coordonnées appropriés à l'échelle du continent (ETRS89, etc.) ? SimonPoole (talk]) 11:25, 21 novembre 2013 (UTC) Une question supplémentaire avec trop de précision : Les outils en aval auront des problèmes pour traiter les flotteurs de haute précision. Par exemple, avec PostGIS, certaines opérations nécessitent ST_SnapToGrid ou un post-traitement avec ST_SetPoint pour obtenir le résultat escompté plutôt que de s'écarter très légèrement de la cible. L'accrochage et la mise en place sont actuellement raisonnablement sûrs, mais uniquement parce que les anomalies géométriques sont évitées grâce à la faible précision des données OSM (avec une plus grande précision, la simplicité des objets ne serait plus assurée). -- [Utilisateur:Ij|Ij ([[Parole d'utilisateur:Ij|talk]) 09:50, 11 octobre 2014 (UTC)

supprimer l'exigence d'atomicité de l'appel POST /api/0.6/changeset/#id/upload

Cet appel API (diff upload) est défini pour fonctionner "atomiquement" ; soit tous les changements dans le document OsmChange téléchargé sont appliqués, soit aucun n'est appliqué. L'exigence d'atomicité rend difficile la mise à l'échelle horizontale du serveur API en distribuant les données cartographiques sur plusieurs machines d'un même groupe. En outre, à mesure que l'OSM se développe, nous devrions servir des données cartographiques provenant de plusieurs centres de données (géographiquement dispersés). Dans un tel contexte, la nécessité de changements "atomiques" serait encore plus gênante. Jkoshy 05:59, 24 novembre 2010 (UTC)

le téléchargement diff n'est pas du tout conçu pour traiter les mises à jour partielles, ce qui n'est pas possible pour l'instant. Mmd (talk]) 22:34, 9 janvier 2020 (UTC)

Trucs amusants

Tous les tags en chinois seulement

Toutes les étiquettes doivent être traduites en chinois, et seuls les caractères chinois devraient être acceptés pour les étiquettes à l'avenir. * Le klingon serait préférable * Je préfère le braille, peu importe que ce soit du braille klingon ou du braille chinois. * [http://www.omniglot.com/writing/tengwar.htm Tengwar] pour être le jeu de caractères par défaut dans l'API et les moteurs de rendu. : -1 pour le klingon. C'est tellement dépassé. Nous avons besoin de noms Na'vi. -- [User:Ivansanchez|Ivansanchez 10:41, 2 février 2010 (UTC)

• Pourquoi pas Baybayin ? -Ianlopez1115 12:57, 4 mars 2010 (UTC)

Voir aussi

• User:Frederik Ramm/Ideas pour API 0.7
• Liste de souhaits des contributeurs - établissement d'une liste plus courte avec des commentaires sur les idées des autres (beaucoup d'idées tirées d'ici)
• User:Zverik/API 0.7 Proposal - une autre courte liste de suggestions qui sont relativement faciles à mettre en œuvre et qui amélioreraient l'expérience des utilisateurs

Et plus généralement...

• Develop - le principal portail de développement de l'OSM
• Bugs - liens vers diverses listes de suivi des bogues
• Top Ten Tasks - Principales initiatives de développement en cours

Demande de déplacement par Erkin Alp Güney ([[Conversation d'utilisateur:Erkinalp|talk])

Vers Talk:API v0.7. 12:20, 28 mars 2017 (UTC)