OK.
Dans les normes S-57 et S-101, il y a un type linéaire et un type surfacique, donc l’introduire n’implique pas de casser le modèle topologique.
Donc on peut ajouter un type area sans tout casser (et effectivement ça change le sens du mesage).
Oui, si la proposition n’était que de créer le type surfacique, cela ne poserait pas tant de problème.
Une seconde proposition est faite : abandonner les nœuds comme sommet des chemins.
Celle-ci force à ce que chaque objet dispose de sa propre géométrie et transforme la base en base de données géographiques.
Avec l’inconvénient de distribuer la vérification de la cohérence entre les différents objets pour maintenir les connections entre eux (un passage piéton sur une route, un passage à niveau au croisement d’une route et d’une voie ferrée, etc…). C’est un point très structurant et j’ai pas encore lu de solution à chacun de ces points.
Là encore on est d’accord : là on casse bien tout, on a déjà eu assez de soucis avec les éditeurs et les relations, faut-il remettre un sous dans la machine ? Oui, là, la question est fermée !
Je ne suis pas sûr de bien saisir ce que ça implique, mais de ce que je comprends, je suis un peu inquiet du résultat sur des zones très chargées, et multi niveaux comme les grandes gares.
En d’autres termes, est-ce que ce modèle est tenable sans ajouter des couches ?
Quand on créé un bâtiment sur iD, on créé un polygone et on lui ajoute les tags approprié pour le qualifier comme un bâtiment.
A aucun moment on a dit si c’était un périmètre fermé ou une surface pleine, les deux existant avec la même géométrie.
Dans ce cas, pourquoi ne pas simplement gérer ces attributs manquants qui serait déduit du type : une clôture = ligne fermée, un parking = surface ?
Pour éviter la redondance, une table de relation type polygone <> type géométrie me parait envisageable.
Ma lecture c’est que cela permet de ne pas mélanger l’API et le tagging. Qu’un certain tag soit valable en tant que surface ou area cela est décidé par la communauté, à chaque éditeur de faire les vérifications nécessaires avant l’upload. Un type area permet à l’API de le refusé s’il y trouve une erreur, sans lien avec le schéma de tagging.
C’est comme cela que cela fonctionne aujourd’hui, chaque utilisateur (pour le rendu d’une carte, le calcul d’itinéraire…) a sa propre table de correspondance dans son coin.
Exemple :
Ça marche, mais c’est pataud.
Remarque en passant : la précision en x,y peut difficilement être au centimètre en raison de l’absence de base d’appui à cette précision, ou de levers GPS professionnels. J’imagine qu’il s’agit d’un affichage de décimales non significatives.
La précision d’OSM (en France) doit se situer entre quelques mètres et disons dix à vingt mètres à cause de l’imprécision du cadastre et donc des bâtiments.
A la lecture des différents commentaires :
- il faut « toucher d’une main tremblante » au système d’origine, il a fait ses preuves;
- les impacts paraissent nombreux et variables sur l’aval. Cela signifie habituellement qu’on ne pourra pas tous les cataloguer et qu’il y aura des effets de bord inattendus.
Pas glop. - de plus, il me semble que ce serait incorporer dans la base elle-même des contraintes liées à certains usages. Comme le dit @Ydel, éviter de mélanger API et tagging.
- dit autrement : quel est le coût de ne rien faire?
- ne vaut-il pas mieux laisser les usagers qui en ont besoin définir les outils dont ils ont besoin plutôt qu’intégrer et donc de prioriser certains en dur?
- en quoi cette évolution (que je vois comme un rapprochement des canons de l’infogéo) contraindrait-elle le futur?
- Venant des BD géo, le modèle OSM m’a paru considérablement plus simple à saisir pour un néophyte. Il serait dommage que les géomaticiens exportent leur compétence et leurs habitudes dans un écosystème qui n’en a pas besoin, je rejoins ici Steve Coast cité par @InfosReseaux en juin « OSM’s design is simple but it’s also a little chaotic for the same reason that it’s simple: It’s a mirror of the human world, which after all is chaotic. »
3 Likes
Pour complérer : officiellement on travaille en WGS 84 - WGS84 - World Geodetic System 1984, used in GPS (les coordonnées GPS) : précision 2 m.
En fait les othophotographies sont en RGF93 v1 / Lambert-93 + NGF-IGN78 height.
Là c’est plus précis (le système suit la dérive des continents). Mais les valeurs ne sont pas les mêmes.
Et comme @Mens_Data le souligne, le cadastre est moins précis car issu initialement de plans papier dont le but est de taxer le foncier : la position exacte n’est pas le souci premier de l’administration fiscale. Il suffit de parcourir le cadatre à la limite entre communes pour voir des sautes dans le cadastre.
Pour avoir une précision décimétrique voir centimétrique, effectivement il vaut un relevé de qualité professionnelle (GPS RTK par exemple) ou de partir des relevés géodésiques de l’IGN et consorts pour travailler en relatif par rapport à ces points.
Donc augmenter le nombre de chiffres permettrait dans le futur d’améliorer la précision mais actuellement de faire croire à une fausse précision.
Si on veut avoir cette hautre précision il faut replacer quasiment tous les points dans OpenStreetMap. Ce ne peut être qu’une amélioration progressive.
Qu’est-ce qui empêche de centraliser un style par défaut (pour cette partie, quitte à changer le formalisme) et que les utilisateurs partent de là ? Question ouverte.
Il ne faut pas mélanger la précision absolue et relative.
Si on s’amusait à supprimer des décimales sous prétexte que la précision absolue d’Osm n’est que métrique, on risque d’avoir quelques soucis pour dessiner des giratoires qui soient rond. Dans le même ordre d’idée, ça deviendrait impossible de positionner précisément un obstacle sur un trottoir dessiné en surfacique.
Donc non, il ne faut pas utiliser la précision absolue pour déterminer le nbre de décimales nécessaires.
Il suffit d’utiliser la BD ortho pour avoir une précision absolue inférieure au mètre.
1 Like
On est d’accord. Je dis juste qu’il ne faut pas prendre ça pour de la précision absolue.
Mais augmenter la possibilité ne changerait à rien à la situation actuelle : aujourd’hui plein d’objets ont une précision bien moins bonne que possible. On voit parfois des objets décaler de plus de 10 m ! Donc augmenter l’espace de stockage pour les x,y, permettrait d’avoir de nouveaux usages sans rien changer (si ce n’est la taille de la bdd …)
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).