osm2xp - Génération batiments via open street maps

[lebelge]

Encore quelques petits "print-screen" (avec mes nouvelles textures) démontrant le potentiel incroyable de cette application que nous prépare BennyBoy (Bonjour à ta petite fille... et profite s'en bien maintenant, parce qu'après, en grandissant, elles deviennent toutes des chipies :yesnod: :lol: ).

Voici Ostende (Mer du Nord)... que Clochette aime bien survoler.
C'est un exemple de mélange possible entre objets (OBJ) et façade (OSM) :




Voici Anvers (Antwerpen), en approche vers EBAW.
Ici, plus de 90% des bâtiments sont générés automatiquement par Osm2XP :




Et enfin (faut pas abuser non plus) un survole de Bruxelles.
Sous l'aile gauche, vous pouvez apercevoir la basilique de Koekelberg.
Sous l'aile droite, dans le fond, c'est l'Atomium.
Les bâtiments devant sont générés automatiquement par l'application de BennyBoy :




lebelge (qui devrait bientôt pouvoir vous offrir des scènes d'enfer grâce à BennyBoy)

[beber]

Justement, tu arrives à créer des exclusions pour préserver l'emplacement des monuments ?

[Daniel_L]

Justement, tu arrives à créer des exclusions pour préserver l'emplacement des monuments ?

Si tu arrives à ouvrir le DSF généré par OSM2XP avec Overlay Editor, là tu devrais pouvoir voir, sélectionner et supprimer les Facades indésirables.

Daniel

[lebelge]

Si tu arrives à ouvrir le DSF généré par OSM2XP avec Overlay Editor, là tu devrais pouvoir voir, sélectionner et supprimer les Facades indésirables.

Daniel

(Ma réponse est aussi valable pour la question de Beber)

Alors voilà, il n'est pas possible (pour le moment) d'ouvrir les DSF générés par OSM2XP via Overlay Editor (ou plus exactement, une fois ouvert, Overlay Editor ne suit plus).

J'en ai parlé à BennyBoy, qui est un homme d'action, et qui m'a dit qu'il n'aimait pas trop Overlay Editor car beaucoup trop lourd, trop lent ... etc. Et, il est vrais qu'avec l'application que BennyBoy nous développe pour le moment, on créé une ville comme Paris en quelques minutes.

Pour une beta proposé en un WE, moi je dis CHAPEAU BAS !!!

Maaaais, évidemment, ... y a encore du travail dessus et (pour le moment) on ne dispose que de 2 types de bâtiments ce qui nous donnent un visuel assez "répétitif" (d'où la nécessité de jongler avec les textures).

Maaaais, si on y glisse quelques bâtiments 3D (comme des monuments historique, cathédrales, tour Eiffel ou Atomium, etc ) l'effet visuel devient plausible (voir "print-screen" de la Belgique ci-dessus)

Alors, pour répondre à vos deux questions (Daniel_L et Beber... tiens... à propos, Daniel_L, pourquoi un seul _L, sur un avion, il y a pourtant bien deux _LL :lol si on ne peut pas éditer les DSF de OSM2XP via Overlay Editor, on peut, par contre, éditer facilement les DSF générés par Overlay Editor et donc faire les exclusions nécessaires (supprimer les .FAC par exemple) depuis ceux-là.

Bref, on inverse les rôles :idea:.

C'est ainsi que mes bâtiments (comme la cathédrale de Koekelberg ou l'Atomium) sont protégés contre l'invasion des objets créent par OSM2XP.

Note:
Faut pas non plus croire que l'application de BennyBoy, aussi génial soit-elle, va pouvoir TOUT faire. Il y a encore un gros boulot derrière pour faire le nettoyage mais c'est, incontestablement, un VRAIS plus pour remplir rapidement des objets qui respectent les textures aux sols.

Seul problème, trouver sur le NET les fichiers OSM.PBF (OpenStreetMap) suffisamment complet pour pouvoir généré suffisamment de bâtiments. Par exemple, pour la Belgique, la ville d'Anvers (Antwerpen) est 4x plus fournis que la capital, Bruxelles ?!!!

lebelge

[Clochette]

Bonjour à ta petite fille... et profite s'en bien maintenant, parce qu'après, en grandissant, elles deviennent toutes des chipies.

Toutes ? :aureola:

lebelge (qui devrait bientôt pouvoir vous offrir des scènes d'enfer grâce à BennyBoy)

J'y retourne ... C'était déjà superbe, là il faudra mettre les pare-soleil !

Annick

[bennyBoy]

Pour vous donner quelques infos sur le développement, l'interface graphique est terminée, c'est vraiment minimaliste pour l'instant , cela permet uniquement de donner les paramètres à l'application sans le faire en ligne de commande:

(cliquez pour voir en taille réelle)



L'aspect de l'interface dépend du système d'exploitation, je poste depuis un pc sous xp, donc ça à la "gueule" xp, sous mac ça aura un aspect mac etc...

A coté de ça je travaille à faire de nouvelles façades, avec des textures plus sympa que celle par défaut d'xplane.
J'expérimente aussi plusieurs pistes pour l'attribution des façades aux bâtiments, j'ai fait une petite méthode qui calcule l'écart entre la latitude et longitude max/min, il faut que je regarde maintenant si c'est une bonne méthode pour identifier un type de batiment.
J'ai aussi fait des stats sur le nombre de vecteurs par bâtiments sur la région languedoc, on retrouve un bon 90% des bâtiments sur 5,6 ou 7 vecteurs, on peut donc se dire qu'en dessous de 8 vecteurs on est sur des habitations et attribuer ainsi les textures.

Voila donc pour l'instant je suis plus à réfléchir sur la bonne façon de répartir les textures, afin de ne pas avoir des bâtiments immenses avec un toit rouge en tuiles par exemple.

Dans l'avenir je pense tester la génération de routes, à terme mon but est d'avoir la création en un clic d'une scène "complète" (avec les réserves exprimés par leBelge plus haut)

[Chouchou2570]

D'accord avec Daniel pour déterminer le type de bâtiment.
Par contre, j'ai un doutes sur l'intérêt immédiat de se creuser la tête pour les routes. D'après ce que j'ai compris, XP10 intégrera d'office les routes et cours d'eau issue d'OSM. Après, çà ne sera peut-être pas à notre gout...et c'est vrai qu'OSM évolue constamment, alors qu'XP à un cycle de 2 ans...

Mouais, c'est peut-être pas bête en fait

Olivier...qui réfléchit trop...

[Daniel_L]

J'expérimente aussi plusieurs pistes pour l'attribution des façades aux bâtiments, j'ai fait une petite méthode qui calcule l'écart entre la latitude et longitude max/min, il faut que je regarde maintenant si c'est une bonne méthode pour identifier un type de batiment.
J'ai aussi fait des stats sur le nombre de vecteurs par bâtiments sur la région languedoc, on retrouve un bon 90% des bâtiments sur 5,6 ou 7 vecteurs, on peut donc se dire qu'en dessous de 8 vecteurs on est sur des habitations et attribuer ainsi les textures.

Avec 4 vecteurs ça peut aussi être une usine. La taille devrait aider. Au dessus d'une certaine surface c'est soit un batiment commercial (supermarché), soit un batiment industriel (usine ou entrepot).

Dans l'avenir je pense tester la génération de routes, à terme mon but est d'avoir la création en un clic d'une scène "complète" (avec les réserves exprimés par leBelge plus haut)

Le traitement des routes existe déjà avec XPOSM, c'est donc moins urgent. Par contre il y a toujours de la place pour les améliorations (temps de traitement, plus grande progressivité pour les ponts,...).

Un autre point qui pourrait être sympa c'est la possibilité d'utiliser plusieurs fichiers OSM pour la même tuile. Exemple, dans mon coin +48+001 touche les régions Centre, Ile de France et Normandie. Et je ne parle pas des coins comme +49+006 qui touche la France, le Luxembourg et l'Allemagne.

Daniel

[bennyBoy]

En effet se baser sur le nombre de vecteur n'est pas une bonne solution, j'ai mis en place ce système sur la dernière version (que je viens d'envoyer) et on se retrouve avec de grands bâtiments pour une texture de maison.

Le calcul de surface en effet a des chances d'être plus précis, mais j'ai un peu peur de la perte de performance (chaque bâtiment doit tester tous ses vecteurs pour connaitre sa "surface", et encore c'est approximatif, je fais une soustraction entre la lat/long max et lat/long minimum, bref à tester).

Les fichiers osm embarquent aussi pour certains noeuds des informations (residential,commercial,industrial etc) , mais ce n'est que pour une infime partie des batiments (il faut que la personne qui ajoute le bâtiment fasse l'effort de renseigner ce genre d'informations).

Mais bon en magouillant un peu on arrivera à terme à quelque chose de crédible, de toutes façons il ne faut pas rêver on n'aura jamais la texture exacte du vrai bâtiment , ou alors pas avant qu'open street map embarque des textures 3d dans ses exports qui feront alors 3to pour une ville

Enfin , maintenant que le soft est relativement stable (j'y pense ça doit toujours bugguer avec une tuile Lat ou long négative, il faut que je m'y penche) , avec une interface graphique qui bien que très/trop simple fait son job, je vais pouvoir me mettre sur ce genre de petites choses qui feront la différence.

[Daniel_L]

En effet se baser sur le nombre de vecteur n'est pas une bonne solution, j'ai mis en place ce système sur la dernière version (que je viens d'envoyer) et on se retrouve avec de grands bâtiments pour une texture de maison.

Le calcul de surface en effet a des chances d'être plus précis, mais j'ai un peu peur de la perte de performance (chaque bâtiment doit tester tous ses vecteurs pour connaitre sa "surface", et encore c'est approximatif, je fais une soustraction entre la lat/long max et lat/long minimum, bref à tester).

Autre point qui devrait permettre de mieux identifier les lieux d'habitation c'est l'épaisseur du bâtiment. On ne peut pas vivre dans un endroit sans fenêtres. Par contre, comment identifier ça dans les données OSM, ça va pas être simple !

Daniel

[bennyBoy]

Malheureusement ,les seules infos dispo dans un fichier osm pour un bâtiment sont une liste de coordonnées et une liste de tags de description.
Souvent le seul tag présent est (dans le cas d'un batiment) building = yes.
Quand on a plus de chance, on a d'autres infos dont je parlais plus haut, du style type résidential, un nom de bâtiment, ou monument, etc

[Al-YOUX]

Bonsoir BennyBoy et bonsoir à tous,

Remarques comme utilisateur Mac :

- la dernière version de Osm2XP (avec sa fenêtre sympa) donne un temp.txt, apparemment complet, mais ne le nomme plus en +lat+long.txt comme dans les versions précédentes.

- une ligne blanche avec retour de ligne entre chaque END_POLYGON et le BEGIN_POLYGON suivant

POLYGON_POINT 2.3152596 49.0392423
END_WINDING
END_POLYGON

BEGIN_POLYGON 0 9 2
BEGIN_WINDING
POLYGON_POINT 2.3283892 49.0354298

ce qui fait de milliers de lignes en plus (Mo en trop) et surtout OverlayEditor Mac n'apprécie pas, très lent. Si une sauvegarde par OE est réalisable il les supprimera et tournera ensuite plus vite.

- idem pour les .fac : une ligne blanche entre chaque ligne du programme, mais c'est simple à rectifier soi-même.

- XGrinder Mac refuse la conversion .txt vers .dsf lorque le fichier créé par Osm2XP est trop volumineux et j'ignore la capacité de conversion de XGrinder en Mo à traiter. (si quelqu'un le sait ?)

- comme je te l'avais dit, je travaille sur les .fac et je vois que tu en as ajouté plusieurs qui sont très correctes, mais une adaptation précise au type de maisons ou bâtiments ne sera pas simple.

Plutôt que de t'envoyer les '.fac' que j'ai faites, j'ai trouvé une mine de .fac dans le dossier -LOWI Extended Version- qui pourraient te servir en faisant aussi un document library.txt et gagner du temps pour tes tests.

Les .osm que j'ai trouvé les plus faciles à manipuler sont celles du cadastre, site que tu as donné.

Peut-être ces observations seront utiles, et aussi bien à moi-même pour des solutions que je n'ai pas trouvées.

Très cordialement.
alain

[Daniel_L]

Premiers essais de mon coté.

Lorsque comme moi on prend l'habitude avec XPOSM de ne pas décompresser les fichiers .osm.bz2 on ne comprend pas pourquoi ça ne fonctionne pas. Le message d'erreur n'est pas parlant du tout (Content is not allowed in prolog).

Et puis au premier vol sur la scène générée, déception. Faut dire que je n'avais pas regardé le site OpenStreetMap avant. Il n'y a pas beaucoup de bâtiments définis vers Dreux. Je reteste demain avec l'Ile de France, là il devrait même y avoir mon immeuble.

Un point rigolo, la cathédrale de Chartres. Ca c'est un bâtiment avec un grand nombre de vecteurs !

Daniel

[bennyBoy]

Humm en effet bien vu pour le temp.txt , j'ai du envoyer le mauvais .jar compilé, j'avais corrigé ça hier soir.
Pour le saut de ligne entre chaque polygon c'etait il me semble aussi le cas avec l'ancienne version, je vais l'enlever.
Pour les lignes blanches dans les .fac, j'ai utilisé world editor, donc il doit sauter des lignes, je penserai à nettoyer le fichier à l'avenir.

Pour xgrinder qui ne veut pas convertir en .dsf, ça m'est aussi arrivé une ou deux fois, je ne pense pas que cela soit relatif à la taille du fichier texte, j'ai réussi à convertir de gros fichiers (presque 100mo) et vu des fichiers de 10 mo ne pas passer.
Pourtant la structure du fichier texte m'avait l'air bonne, je ne vois pas trop ce qui peut bloquer, et xgrinder ne donne pas d'erreur (il y a peut être un fichier log dans son répertoire, je regarderai).
Donc à creuser, peut être la définition d'un polygone qui ne plait pas à xgrinder, genre vecteurs qui se croisent, à voir.

Pour le message d'erreur sur le fichier .bz2, la console osm2xp affiche -actuellement-bêtement les erreurs telles quelles, donc l'erreur affichée est celle renvoyée par l'objet de lecture de fichier xml, qui ne trouve pas dans un fichier .bz2 la structure attendue.
J'ajouterais dans la fenêtre "parcourir" une restriction sur le type de fichiers autorisés.

Enfin Daniel pour dreux je te conseille d'utiliser le fichier suivant : http://cadastre.osm.cleo-carto.org/0...EUX-houses.osm , j'ai fait un test rapide sans lancer xplane, mais osm2xp génère 13'126 bâtiments, ce qui me semble réaliste pour une ville de 30'000 habitants.

Les fichiers de http://cadastre.osm.cleo-carto.org sont beaucoup plus fournis en bâtiments que ceux de geofabrik, mais sont restreints à une ville.
Dans l'avenir je pourrai ajouter une méthode de génération qui accepte un lot de fichier osm pour pouvoir créer une région avec les fichiers de cleo-carto par exemple.


edit: pour l'histoire du fichier qui ne se renomme pas en lat/long.txt, j'ai retesté mais sur un poste windows (le test que je venais de faire était sur mac), et ça marche.
Donc c'est uniquement sur mac , je m'occupe de corriger ça ce weekend.

[Al-YOUX]

edit: pour l'histoire du fichier qui ne se renomme pas en lat/long.txt, j'ai retesté mais sur un poste windows (le test que je venais de faire était sur mac), et ça marche.
Donc c'est uniquement sur mac , je m'occupe de corriger ça ce weekend.

Bonjour BennyBoy,
J'ai pu refaire un contrôle avec ton même dernier Osm2XP sur Mac OS X puis sur Windows 7

Clermont.osm
résultat avec Mac OS X --> temp.txt de 12,4 Mo
résultat avec Windows 7 --> +45+003.txt de 12,9 Mo

Donc, le document est bien effectivement renommé sous Windows et un peu plus volumineux.

alain