Heu… Je disconviens. La précision de la BDOrtho est théoriquement du mètre si pixel de 50cm, et elle est en général un peu (voir beaucoup selon modelé de terrain) moins bonne en raison de la faible précision du modèle numérique de terrain utilisé pour l’ortho-rectification.
Sans parler de l’effet perspective par rapport au nadir de la prise de vue.
Donc un à deux mètres de précision absolue me paraît une évaluation prudente.
Dans un document de 2014, l’Ign annonce :
L’objectif pour la BD ORTHO® ou l’ORTHO HR®, lorsque les données sources le permettent, est
une exactitude planimétrique absolue (exprimée en moyenne quadratique) meilleure que 0,8 m.
Il est exceptionnel qu’elle dépasse 1 m.
On peut imaginer que c’est encore mieux presque 10 ans plus tard, mais je ne trouve pas les tableaux mentionnés dans le descriptif actuel
Mais bon, on commence à être bien hors sujet. On peut continuer à en discuter ailleurs.
Il y a aussi OSM history qui affiche l’historique des géométries, sans dépendre d’un changeset récent.
Il serait intéressant de voir d’où vient cette proposition. Si ça vient des géomaticiens des principaux acteurs ça en dirait long sur leur envir de pousser les contributeurs bénévoles sur la touche. Ou pour faire en sorte que les outils permettant de faire n’importe quoi de rendre la base inutilisable dans la pratique. J’espère que tel n’est pas le cas et que certains veulent seulement reproduire leur modèle.
Je proposerais bien de motifier le modèle pour passer à un modèle matriciel, Mais même un premier avril ça risquerait d’être pris au premier degré.
Tu pense à cartographier individuellement chaque gravillon ? 
OpenStreetMap n’est pas un BIM (modèle pour le bâtiment).
Côté « z » on a préféré jusqu’à présent rester sur des points précis (ele des points géodésiques) et en symbolique (nombre d’étage, hauteur d’un bâtiment) permettant d’avoir les principales informations pour créer un modèle 3D ce qui permet déjà de faire des choses potables. Comme cette information est par nature absente des plans (sauf BIM et relevés topo souvents privés) et difficile à acquérir (quel référentiel ? Absolu ? Par rapport au terrain « naturel » ?), je propose déjà qu’on améliore l’existant. Je n’ai pas de souci si un réseau d’eau donne les élévations à certains points. Par contre je vais avoir du mal à y contribuer en tant qu’unidividu.
Concernant l’altitude, en général on intègre un MNT (modèle numérique de terrain) par exemple pour faire des carte topographiques. Typiquement des données matricielles ;-), conservées à par (pour une hauteur tous les 250 m en moyenne, compte plus de 4 Go).
Après tu vas sans doute utiliser un MNS (modèle numérique de terrain) pour évaluer les hauteurs de bâtiments dont tu n’as pas la hauteur.
Retour sur le modèle : un truc qui me chagrine c’est qu’on ne pousse pas plus loin les DataItem (données du wiki utilisable par une machine). Il me semblerait aussi utilse de pouvoir créer des données non géographiques (par exemple décrire La Poste comme une entreprise postale et ce qui permettrait de contrôler (valider) les informations asscociées. Par exemple si cette entreprise à une référence pour ses bureaux de poste, on incite à mettre cette référence et ensuite des informations telles que le lien vers la page du bureau de poste est généré automatiquement). Idée à préciser.
Tu pense à cartographier individuellement chaque gravillon ?
Ne me tente pas … 
Je n’aurai personnellement aucune utilisation pratique d’augmenter la précision, mais je pense que pour certains (pro) ca peut être utile, je pense par exemple aux points géodésiques, la précision absolue est meilleure que la précision possible dans OSM. Je ne souhaite qu’ouvrir la discussion sur ce sujet, en espérant augmenter le nombre d’utilisateurs … et donc de contributeur.
Côté « z » on a préféré jusqu’à présent rester sur des points précis
Je suis d’accord, avec un MNT en sus d’OSM OsmAnd ou FatMap font des choses fantastiques. Pour les modèles 3D, je suis d’accord qu’on peut faire de très belles choses, je me suis aussi amuser à en faire un et certains font des choses magnifiques. Je ne voulais faire qu’ouvrir la discussion (et pas sûr que ce soit très pertinent de rajouter un z très honnêtement).
un truc qui me chagrine c’est qu’on ne pousse pas plus loin les DataItem
Tu veux parler de wikidata ? Ca me chagrine aussi, cf le sujet que j’ai ouvert hier. On pourrait utiliser bien plus que les name:xx et alt_name:xx= ; pleins d’autres infos seraient exploitables. Et surtout amène des contributeurs extérieurs à OSM. Mais qui utilise les infos dans les wikidata liées aux objets OSM ? J’ai l’impression que pas grand monde alors que c’est extrêmement riche.
En faisant pas mal de contribution indoor, on tombe régulièrement sur un problème : A cause de la pente du terrain naturel, le niveau 0 d’un bâtiment sur une facade peut être le niveau -1 sur l’autre. Indiquer la hauteur pourrait être une solution (notez le conditionnel).
Mais est-ce que ça fait partie de l’évolution du modèle de donnée ? Je n’en ai pas l’impression.
J’ai pris un point au hasard précision < 10 cm en lat,lon et < 50 cm en ele.
Là on est plus précis que le système de coordonnées utilisé par OpenStreetMap. Donc comme il s’agit de précision absolue, tu dois passer du CRS84 à des systèmes différents (RGF93 (ETRS89) en France (Europe)) se recalant en fonction de la date. C’est effectivement un chantier possible, plus important dans d’autres parties du monde.
Non je parle bien des DataItems, la version plus formalisée du wiki OpenStreetMap. Ça correspond aux Wikidata (dont ça reprend le formalisme) mais plus pour la partie métadonnées. Je vais répondre à propos des name* sur le fil correspondant.
height existe déjà, point un bâtiment c’est la différence entre le point le plus bas du terrain et le point le plus haut de la partie non mobile du bâti (pas des antennes). J’aurais tendance à prendre comme niveau 0 le RdC à partir du point le plus bas. Ceci-dit, ce qui est le plus important c’est de rester cohérent pour le même bâti. Chez Siemens le RdC c’est le niveau 3. C’est une référence comme une autre ;-).
J’ai l’impression que sur l’indoor le problème est plus l’édition (mais je pratique peu) et éventuellement la capacité à intégrer facilement des modèles BIM. Intégrer côté appli, pas ingérer dans la base (ou dans une partie non distribuée par défaut).