Je dois dire que la démo dans Osm2xp est BEAUCOUP plus convaincante (et très réussie) que cette démo dans Map.F4-Group, qui n'est encore qu'une ébauche. Là au moins il y a eu un gros travail de modélisation avec des valeurs par défaut dans les zones, et la constitution de bases libres de modèles 3D et de bases de textures (c'est réutilisable pour d'autres applications).
Sans compter que le rendu d'Osm2XP est temps réel, même si cela demande un téléchargemetn d'un logiciel spécifique et d'une base préparée spécifiquement dans une zone limitée de navigation (il reste à OSM2XP à créer un système permettant une téléchargement en arrière-plan des bases préparées dans les zones voisines). Mais on ne doit pas exclure qu'Osm2XP développe une version plugin pour navigateur ou une Application pour smartphone, utilisant les fruits de son travail génial. Ses solutions adoptées marchent visiblement bien sans trop de travail et sans surcharger la base OSM elle-même. Osm2XP a déjà fait l'objet d'articles élogieux sur les blogues d'OSM. Là où ça se corse c'est qu'au delà de ce rendu réaliste, une application va vouloir intégrer d'autres données. Des options de rendu sont à revoir, notamment rendre semi transparents les bâtiments trop proches pour voir ce qui est dedans ou derrière, sinon on ne peut même pas lire les libellés des rues. Des tas de détails voudront s'afficher quelque part : accessibilité par exemple, options de navigation et routage, sens et restrictions de circulation, panneaux routiers, noms visibles sue les enseignes des magasins... Pour le mapping intérieur des bâtiments ouverts au public, il faut trouver des solutions aussi (les textures des façades ne sont plus d'aucune utilité, on voudra voir des plafonds, des couloirs des vitrines dans les galeries marchandes, les portes d'accès au métro, les bornes de vente de tickets, les escalators, les rampes des escaliers). Mais on rentre là dans le micromapping qui a besoin d'autres solutions pas encore développées par Osm2xp qui se concentre pour l'instant dans le rendu aérien, et en fait pas encore dans le rendu de navigation au sol, qui sera pourtant pourtant utile déjà pour la navigation routière, qui fait l'objet d'une grosse demande, sans doute même la plus importante en cartographie de la part du grand public... Et là il nous manque la navigation avec indication des voies de circulation, et OSM peut encore largement s'améliorer, tant pour les conducteurs de véhicules que les cyclistes et piétons). OSM en revanche cherche un moyen de mieux intégrer les modèles d'altitude du terrain à très grande échelle (le monde entier) : où trouver ces données ? Il faudrait que la base OSM enregistre quelquepart les modèles altimétriques utilisables (une URL mentionnée dans certaines zones géographiques ou administratives? A quel niveau peut-on interroger la base ?). Les tags ele=* étant largement insuffisants, voire inutiles sur autre chose que les constructions, dans l'état actuel, ou juste utiles comme une métadonnée ponctuelle pour les sommets et les points géodésiques. ---- Transition vers des données 3D et compatibilité --- A terme il faudrait que les "noeuds" d'OSM puissent tous contenir une 3e coordonnée standardisée d'élévation, utilisant une référence d'altitude soit implicite par défaut, soit associée au noeud (pour la 2D la référence unique WGS84 a été adoptée, mais rien de clair actuellement pour l'altitude qui n'est pas portable, alors que les systèmes géodésiques 3D sont déjà normalisés : on peut faire un choix et imposer de convertir les autres modèles 3D vers celui-là; mais si on veut faire simple, un noeud 3D devrait utiliser directement les coordonnées cartésiennes avec les 3 axes sur l'axe des pôles géographiques vers le Nord, les 2 autres axes sur le plan équatorial vers les méridiens de 0°¨ et de 90°E, et l'unité de mesure en mètres réels). Les noeuds 2D en projection WGS84 devraient implicitement avoir une conversion en coordonnées 3D utilisant par défaut l'ellipsoïde de référence (même si ce géoïde n'est pas exactement au niveau du sol) et un modèle pour la verticale de référence : l'intérêt d'avoir la 3e coordonnée sera de pouvoir corriger cette atltitude selon ce que représente le noeud. On peut alors faire la conversion inverse (3D vers 2D) en utilisant la verticale de référence pour projeter sur le géoïde et obtenir les coordonnées WGS84. Ces formules de conversion devraient être documentées. Sans rien changer d'autre aux modèles XML d'OSM que l'ajout d'un troisième attribut optionnel ele="*" dans les noeuds en plus de lat="*" et lon="*", ou bien en utilisant directement x="*", y="*", z="*", l'API OSM permettant aussi de spécifier le type de coordonnées qu'on veut obtenir (2D WGS84, ou 3D cartésienne) si on veut garder la compatibalité totale avec les applis existantes (cependant dans ce cas l'API devrait éviter de perdre la 3e coordonnée totalement, le serveur qui a déjà des coordonnées 3D devrait alors ajouter un tag standard aux noeuds. Par exemple "_osm:ele=*", en indiquant que le préfixe "_osm:" dans un tag est réservé et ne peut être utilisé par autre chose; pour permettre de déplacer un noeud en 2D, la conservation de cette 3e coordonnée ne peut pas être au format cartésien mais devrait être une mesure le long de la verticale de référence - si le serveur détecte que le noeud 2D déplacé est trop éloigné du noeud 3D d'origine, et entraine un changement notable (plus de 2 degrés par exemple) des angles de pentes, il devrait indiquer alors au client qu'il a remplacé un noeud par un autre nouveau, ou bien ne rien dire et juste créer un nouveau noued supplémentaire sans tag. - l'ancien noeud 3D est gardé à sa place mais plus connecté aux ways, il perd ses tags mais est gardé comme référence altimétrique s'il apportait une correction altimétrique suffisante par rapport à ses anciens noeuds 3D voisins, ce noeud peut aussi gagner un tag "_osm:keep=altimetry" et rester invisible aux requêtes de l'API en mode 2D, il pourrait aussi être invisible aux clients 3D qui ne veulent pas y toucher. - le nouveau noeud 2D trop éloigné reste dans la base alors en 2D (avec son altitude implicite à la surface du géoïde de référence ou calculée par triangulation sur les noeuds 3D voisins ayant des tags indiquant une altimétrie; à charge des moteurs de rendus s'ils veulent faire cette triangulation). - le tag "_osm:ele=*" sera très souvent différent en valeur du tag existant "ele=*" qui est ambigu au sujet de sa référence 0 (mesure depuis le niveau du sol, ou meure depuis le niveau de la mer de référence, variable selon les pays ou régions...), car il devra utiliser un modèle de référence unique. Je suggère une altitude mesurée en mètres, depuis la surface du géoïde définissant l'altitude 0, et le long d'une verticale de référence simple liant le noeud à l'unique centre du géoïde de référence, et tant pis si cela ne correspond pas à l'altitude "officielle" dans un pays donné qui utiliserait d'autres modèles pour la verticale et pour l'altitude de référence du "niveau de la mer". En effet la "vraie" verticale, celle du fil à plomb, subit l'effet de l'accélération due à la rotation de la Terre (qui s'ajoute à l'accélération de pesanteur dès lors qu'on est lié au sol, c'est plus compliqué à mesurer si on est dans le ciel ou en déplacement à cause des accélérations de ces déplacements), ces verticales locales ne passant pas toutes dans le monde entier par un centre unique de la Terre mais plutôt vers un point décalé du centre le long de l'axe des pôles géographiques, ce point dépendant de la latitude (à la surface du géoïde de référence, tous les points à une même latitude, donc le long d'un cercle parallèle au plan équatorial, ont leur verticale locale passant par un même point situé sur l'axe des pôle; un calcul assez simple permet de savoir quelle est la composante d'accélération non liés à la pesanteur mais à la rotation, le résultat dépend de la vitesse de rotation de la terre qui doit aussi être modélisée par le choix du modèle de référence (elle n'est pas si constante que ça si on cherche à être très précis, mais l'axe de rotation terrestre subit aussi quelques modifications et tout aussi irrégulières et imprévisibles). Autre effet de cette accélération de rotation: plus on s'élève en altitude, moins l'accélération de pesanteur se fait sentir, alors que l'accélération de due à la rotation reste toujours là (le couple est inchangé). La direction de la verticale s'écarte donc de plus en plus de celle de la pesanteur pour se rapprocher de la direction sur le plan équatorial, orthogonal à l'axe polaire de rotation (si on est déjà à sur l'équateur, la force résultante change bien, mais pas en direction, le changement de direction de la verticale s'accentue avec la latitude). Cela a toutes une série d'effets très visibles en terme de climatologie, tant dans l'atmosphère que sur les courants marins ; ou encore sur le tourbillon qui se forme au vidage de l'eau dans votre lavabo ou votre baignoire (et qui tourne toujours dans le même sens selon qu'on est dans l'hémisphère nord ou sud, mais qui ne se forme pas de façon stable à l'équateur) : la verticale du fil à plomb, qu'on mesure localement en s'appuyant sur un point terrestre "fixe", n'a rien à voir avec celle qu'on mesure en déplacement. Mais un modèle de verticale plus proche du comportement du fil à plomb, tendu depuis un point fixe lié à la surface du géoïde de référence (et non la verticale de chute libre sans frottement et sans vitesse initiale, qui est la verticale de pesanteur) pourrait aussi être choisi, si c'est bien documenté pour faciliter la conversion automatique et fiable en coordonnées 3D cartésiennes. On devrait aussi pouvoir interroger la base sur les coordonnées 3D cartésiennes d'un vecteur unitaire donnant la verticale de référence applicable à un jeu de donnes en 3D cartésienne obtenues depuis la base (ce qui simplifiera le rendu 3D qui peut alors savoir comment représenter cette verticale réelle par une verticale à l'écran. Le 28 juin 2013 17:00, Ab_fab <gamma....@gmail.com> a écrit : > Pas con, ça pourrait donner ça au final : http://osm2xp.com/ > > > Le 28 juin 2013 16:57, Philippe Verdy <verd...@wanadoo.fr> a écrit : > > Le modèle par défaut privilégie des hauteurs uniques et des toits plats. >> Il manque une façon d'indiquer des toits à simple ou double pente, avec des >> tags simples, meme sans entrer dans trop de précision. Aussi le type de >> couverture (zinc, ciment, tuiles, ardoise, couverture végétale) >> Taguer les bâtiments un par un n'est pas réaliste, on n'y arrivera jamais >> alors qu'il y a souvent des zones d'urbanisation qui pourraient mentionner >> ces éléments par défaut (notamment les zones de land_use=*, y incluant des >> membres pour des catégories de construction), pour qu'on n'ait pas besoin >> de taguer complètement tous les bâtiments (par exemple ces règles associées >> dans les land_use indiqueraient que les constructions sont majoritairement >> en brique, et à toit à double pente couvertes de tuiles, pour les batiments >> résidentiels). >> >> D'autres règles pourraient être crées pour les batiments commerciaux (on >> a déjà une classification des types de batiments, distinguant par exemple >> les hangars, les chateaux d'eau, les pylones; on pourrait ajouter des >> règles pour les tours de plus de 3 étages au dessus du RDC). La majorité >> des batiments à toits en pente sont à double pente, il devrait y avoir un >> angle par défaut, et la position des pentes peut être estimée directement >> depuis le contour polygonal externe du bâtiment, en déterminant son >> squelette filaire et prolongeant les segments terminaux en direction du >> contour externe. >> >> Dans trop entrer dans le détail, le rendu peut donc largement >> s'automatiser, et devenir bien meilleur, pour l'affiner ensuite seulement >> pour ce qui est nécessaire localement comme des exceptions (on peut ignorer >> des différences mineures comme des écarts d'angle de pentes: on commence >> d'abord par ce qui est le plus évident et le plus repérable au premier coup >> d'oeil pour le repérage : la nature visible des façades et leur couleur est >> plus évidente que le dessin exact des pentes de toits et la présence des >> cheminées ou antennes sur les toits). >> >> Certains voudront ensuite détailler certaines zones davantage, mais on ne >> devrait pas trop s'attarder sur des détails excessifs comme la modélisation >> exacte de la tour Eiffel, qui ne sont que des démos pas reproductibles à >> grande échelle (trop de travail, et cela se fai de toute façon sur des >> bases de données de modèles 3D externes à OSM pour certains bâtiments >> remarquables, type: Tour Eiffel, Pont du Gard, Viaduc de Millau, les grands >> chateaux et constructions miitaires, les cathédrales). Dans certains >> secteurs les bâtiments ont des formes très spécifiques (notamment les >> immeubles de résidences dans des zones balnéaires, ou dans certaines >> villes, avec des décrochements et trouées nombreux sur les façades). En >> façade il y a des modèles pour les balcons dispersés, pour les escaliers de >> secours, mais certainement moyen de les catégoriser au moins par zone >> d'urbanisation (tenant compte des règles d'urbanisme locales qui limitent >> les apparences). >> >> Il serait bon aussi de savoir où aller chercher ces bases externes de >> modèles 3D pour des bâtiments spécifiques géolocalisés. Car cela se fait >> dans le désordre (et rien ne l'indique par une URL dans la base OSM, tout >> bonnement car il n'y a pas encore de standardisation des formats de ces >> modèles 3D supportables, ni assez d'outils pour permettre les conversions >> automatiques, au moins partielles mais suffisantes, entre ces formats ; la >> tentation est forte d'utiliser les formats de modèles 3D documentés par >> Google, mais encore eux aussi expérimentaux et sujets à évolutions). >> >> On devrait même (sans modélisation 3D véritable) disposer d'une base >> externe contenant des textures de façades type (créées à partir de photos, >> anonymisées et alignées pour permettre leur utilisation pas compliquée pour >> un tuilage, et quelques règles indiquant la façon de disposer les tuiles ou >> permettant ou pas de couper les carreaux, et éviter de se retrouver avec >> des morceaux de portes ou de fenêtres avec leurs lintaux). Ce qui veut dire >> un moyen de constituer des bases externes de textures 2D, en plus des bases >> de modèles 3D, et de les référencer (URL?) ou d'associer ces textures aux >> modèles 3D directement. >> >> >> >> >> Le 28 juin 2013 16:01, V de Chateau-Thierry <v...@laposte.net> a écrit : >> >> Bonjour, >>> >>> > De : "Nolwenn" >>> > >>> > À Lyon la tour de la Part Dieu rend pas mal et on peut voir la tour >>> Oxygène à >>> > côté. >>> >>> La Défense a du vrai aussi : >>> >>> http://map.f4-group.com/#lon=2.2517171&lat=48.8820713&zoom=17&camera.theta=80 >>> >>> mais la Seine y coule d'aval vers amont ;-) >>> Ça n'enlève rien à l'effet général que je trouve réussi. C'est le genre >>> de vitrine >>> qui peut mieux qu'un long discours motiver pour renseigner les hauteurs >>> de bâtiments. >>> >>> vincent >>> >>> Une messagerie gratuite, garantie à vie et des services en plus, ça vous >>> tente ? >>> Je crée ma boîte mail www.laposte.net >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-fr >>> >> >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-fr >> >> > > > -- > ab_fab <http://wiki.openstreetmap.org/wiki/User:Ab_fab> > "Il n'y a pas de pas perdus", Nadja > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
