Page 6 sur 8 PremièrePremière ... 45678 DernièreDernière
Affichage des résultats 51 à 60 sur 76

Discussion: Projet Z - Recensement de l'orthotographie libre

      
   
  1. #51
    Utilisateur enregistré
    Date d'inscription
    février 2016
    Localisation
    LFLP
    Âge
    76
    Messages
    542
    Total Downloaded
    0
    Citation Envoyé par Oscar Pilote Voir le message
    Il y a un domaine où je vous demanderai sans doute la main plus tard, lorsqu'il s'agira de modifier le trait de côte dans JOSM (localement, pas en ligne) pour lui faire suivre exactement sa position dans l'imagerie (fonction de la marée donc non automatisable).
    Bonsoir Oscar, question de béotien :
    pourquoi passer par JOSM et pas directement sur OSM.org
    Asus Z390-E , I7-9700K 32Gb (3200 Mz)- SSD 950Pro 256 Gb - SSHD 1Tb - 2 x HDD 3Tb - 6Tb HDD USB_3.1 - 4Tb HDD USB3.0 - Asus Strix 1070 (Driver 390.129)- ThrustMaster T-Flight Hotas
    Ubuntu 18.04.2 LTS 64bits
    X-Plane 11.36r2. 11.40r2 Avions : A350XWB FF, Cessna172 airfoillabs, B737-800X,A319 TolissV1p3p3, DA62,Pipistrel-Panthera,B17G, P-51

  2. #52
    Utilisateur enregistré
    Date d'inscription
    décembre 2014
    Localisation
    Paris / Savoie
    Âge
    44
    Messages
    1 960
    Total Downloaded
    0
    Citation Envoyé par papet30 Voir le message
    Bonsoir Oscar, question de béotien :
    pourquoi passer par JOSM et pas directement sur OSM.org
    openstreetmap.org c'est un site web, qui contient notamment le visualiseur de carte, alors que JOSM (J pour Java) c'est
    le logiciel qui est utilisé par 99% des "mappeurs" OSM pour encoder leurs modifications.
    Le site propose des outils en lignes aussi mais ils sont rudimentaires et beaucoup moins fluides que JOSM.

    On peut utiliser JOSM pour modifier OSM (i.e. uploader les modifs) mais aussi pour éditer des fichiers .osm locaux.
    Si ta question était pourquoi le faire sur des fichiers locaux plutôt que en ligne la réponse est : parce qu'il y a une
    définition géographique du trait de côte et qu'on ne "peut" pas (de droit si, mais il sera remodifié derrière par un mappeur en colère ;-)
    le modifier à notre guise pour le faire correspondre au niveau de la marée dans notre imagerie.
    Linux Debian sid - Intel i7 4Ghz - 8Gb RAM - Nvidia GTX 970
    Ortho4XP v130 : Dépôt github (mises à jour au fil de l'eau), ou Version clés en main sous Windows.

  3. #53
    Utilisateur enregistré
    Date d'inscription
    décembre 2014
    Localisation
    Paris / Savoie
    Âge
    44
    Messages
    1 960
    Total Downloaded
    0
    Région Grand-Est, Aube et Haute Marne seront disponibles en open data en mi 2017 et Ardennes et Marne en fin 2017.
    Le reste est déjà disponible (cfr plus haut) et presqu'entièrement mouliné.

    Il y a un truc que je n'ai pas encore évoqué c'est la gestion des frontières. Données libres pour Belgique, Luxembourg,
    Italie et Espagne. La frontière avec l'Allemagne en ok en dehors du Bade Wurtemberg (j'ai appelé hier, ils sont désolés
    mais n'ont pas de version libre). La Suisse... c'est beau mais c'est cher, mais ils finiront eux aussi par y venir.
    Linux Debian sid - Intel i7 4Ghz - 8Gb RAM - Nvidia GTX 970
    Ortho4XP v130 : Dépôt github (mises à jour au fil de l'eau), ou Version clés en main sous Windows.

  4. #54
    Utilisateur enregistré
    Date d'inscription
    août 2011
    Localisation
    Non loin d'EBTN
    Messages
    55
    Total Downloaded
    0
    Citation Envoyé par Oscar Pilote Voir le message
    Données libres pour Belgique, Luxembourg,
    Et comment qu'on peut donner un coup de main, une fois ?
    J'ai mappé la Belgique/Luxbg assez correctement (ça n'engage que moi hein) dans mes premières expérimentations orthoforixpéèsques mais si il y a moyen de faire mieux et de partager, je suis tout ouï...
    Heureux sont les fêlés car ils laissent passer la Lumière.

  5. #55
    Utilisateur enregistré
    Date d'inscription
    août 2011
    Localisation
    Non loin d'EBTN
    Messages
    55
    Total Downloaded
    0
    Citation Envoyé par Oscar Pilote Voir le message
    Il restera deux choses que je me suis bien gardé d'évoquer pour l'instant : le choix des ZL et des ajustements colorimétriques...
    En partant du vieil adage "qui peut le plus, peut le moins", serait-il possible:
    - de publier du ZL correct (ZL17 min) pour tout le monde
    - de fournir l'information nécessaire au "downgrade" aux utilisateurs voulant moins précis pour x ou y raisons tout à fait valables

    Ce serait pas mal ça non ?

    Le souci c'est que la conversion d'un DDS ça prend trois plombes contrairement à la même opération sur les sources en JPG :-(
    Heureux sont les fêlés car ils laissent passer la Lumière.

  6. #56
    Moderateur Avatar de Pascal
    Date d'inscription
    décembre 2008
    Localisation
    A l'ouest, complètement à l'ouest ... de l'europe
    Âge
    58
    Messages
    2 057
    Total Downloaded
    0
    Salut !

    Citation Envoyé par TBone Voir le message
    En partant du vieil adage "qui peut le plus, peut le moins", serait-il possible:
    - de publier du ZL correct (ZL17 min) pour tout le monde
    - de fournir l'information nécessaire au "downgrade" aux utilisateurs voulant moins précis pour x ou y raisons tout à fait valables
    Malheureusement la devise "qui peut le plus peut le moins" s'applique très mal (voire pas du tout) aux zonephoto.

    Changer de niveau de zoom pourrait être réalisé en redimensionnant à mi-résolution chaque fichier DDS (en ôtant le mipmap de plus grande taille), mais alors on perdrait aussi tous les avantages liées à un ZL plus faible : moins de découpes du mesh, donc moins de points à tracer et meilleur FPS.

    En pratique, pour ceux qui auraient une carte graphique permettant l'utilisation du ZL17, il n'y aurait quasiment pas de changement de performance en passant au ZL16. Pour ceux qui seraient trop limites pour utiliser du ZL17, alors il ne resterait rien d'utilisable.


    Autre difficulté, les hébergements n'offrant pas des volumes illimités, diffuser du ZL17 au lieu de ZL16 implique de diviser par 4 la surface couverte.

    Pour la mise à jour qui va venir, si j'ai bien compris, Oscar nos prépare un mix : les tuiles seront globalement en ZL16 (ce qui est amplement suffisant pour les vol > 1500 pieds) avec les zones intéressantes (aeroportuaires, ...) en ZL17 à 18.

  7. #57
    Utilisateur enregistré
    Date d'inscription
    août 2011
    Localisation
    Non loin d'EBTN
    Messages
    55
    Total Downloaded
    0
    Tant que ça plaît aux rétines, ZL16, 17, 18 ou 99, peu importe finalement
    Merci!
    Heureux sont les fêlés car ils laissent passer la Lumière.

  8. #58
    Utilisateur enregistré
    Date d'inscription
    décembre 2014
    Localisation
    Paris / Savoie
    Âge
    44
    Messages
    1 960
    Total Downloaded
    0
    Le ZL16 c'est un juste milieu mais qui a le cul entre deux chaises.
    En IFR c'est inutilement élevé à altitude de croisière, et en VFR ça pique un peu les yeux.

    Les résolutions "optimales" (en considérant 60° d'angle de vision et un moniteur à 96dpi) sont en gros de 1m/pix par 5000ft d'altitude sol.
    Optimales signifiant ici que tout ce qui est supérieur n'apportera plus aucun changement à l'écran.
    Le ZL16 à nos latitudes c'est 1.6m/pix, donc ce n'est optimal qu'à 8000ft, mais cela reste assez raisonnable jusqu'à 2000ft environ (et comme
    ce que chacun appellera raisonnable est ô combien subjectif la page http://simheaven.com/?page_id=8 d'Armin a le mérite de montrer
    les différences, ATTENTION il faut regarder les images à pleine résolution pour comprendre, pas les imagettes!).

    Un dilemme cornélien...
    (sauf là où il n'y a que du 5m/pix de disponible )
    Linux Debian sid - Intel i7 4Ghz - 8Gb RAM - Nvidia GTX 970
    Ortho4XP v130 : Dépôt github (mises à jour au fil de l'eau), ou Version clés en main sous Windows.

  9. #59
    Utilisateur enregistré Avatar de Dobro
    Date d'inscription
    juin 2012
    Localisation
    43
    Âge
    55
    Messages
    871
    Total Downloaded
    0
    Z17 , je trouve vraiment correcte perso ...
    Site: http://michel.dobro.free.fr
    Twitch : https://www.twitch.tv/dobro013
    Msi GT72 Vr Dominator Pro Tobii Eyes (i7 6700HQ,16GoRam DDR4 , Nvidia GTX 1060 , 6Go DDR5 , 17pouces Mat , 1920x1080(Full HD) , 1 SSd 256go, 1 Disks Dur 1 To )(win10)
    http://www.x-plane.fr/image.php?type=sigpic&userid=41003&dateline=143038  2388

  10. #60
    Utilisateur enregistré
    Date d'inscription
    mai 2016
    Localisation
    France
    Âge
    42
    Messages
    115
    Total Downloaded
    0
    Hello,

    Je vote "pour" le ZL17 :-) lol

    Sans vouloir lancer le débat un peu plus, je comprend le souci du volume de donné sur le serveur, et chez sois, sans compter la problématique du temps de téléchargement pour les petits débits.
    Je le sais bien, je suis concerné par le deuxième point et en plus j'ai un disque dur trop limité ^^

    Pour autant, la technologie évolue très vite et la notion de ZL "réaliste" / "de qualité", très subjective, évolue au même rythme. Au point, que rapidement du ZL16 paraitra très pixelisé à pas mal de monde dans même pas 1 an.
    Et pour faire principalement du VFR (en simu comme en vrai), je trouve que la différence (écran 24 pouces, 1920*) entre du ZL16 et ZL17 se voit clairement même à 2000 pieds. Il faut monter à 3000 pour vraiment avoir un doute. Or découvrir les côtes ou des points d'intérêt, c'est plus sympa à 1000 ou 1500 pieds. Je ne parle pas des zones montagneuses ou l'altitude des massif rend le ZL très rapidement lisible...
    Si on monte à des FL de liner, là forcément pas de différence, mais dans ce cas un ZL15 voir 14 est suffisant.

    Voilà, c'était juste mon avis, qui ne vaut ni plus ni moins qu'un autre, mais au moins je l'aurais partagé !
    Bonne journée,

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •