Ils notent en particulier que la réaction de Debian, qui est mentionnée également dans les liens de cet article LinuxFR, a été faite juste après la publication du texte final du CRA et ne prend pas en compte à priori certains éléments, rendant l'analyse pas totalement juste.
Clairement, il va falloir un peu de temps pour bien comprendre les implications pour les différents types d'acteurs de l'écosystème. Il semble à première vue qu'on est pas sur la catastrophe du texte initial, mais il est également clair que ce texte aura un impact sur l'écosystème OpenSource ( mais aussi sur tout l'écosystème IT européen voire mondial ). Il y a des points positifs et d'autres qui le sont moins, les lignes vont bouger, il faudra savoir s'adapter au mieux.
Ce serait intéressant que le CNLL finance une étude un peu approfondie pour clarifier les impacts pour les communautés de développeurs, les fondations, et les différents types d'entreprises du libre ( intégrateurs, éditeurs, ENL/SSLL… ), ainsi que les actions à mettre en place.
Dans la même veine pour les petits, il y a le projet PhonieBox : un assemblage sans soudure avec un Raspberry Pi. En terme d'interface ce sont des cartes RFID ( ou des puces à coller sur des objets ) qu'on peut associer à des albums.
Je ne sais pas bien dans quel contexte tu travailles, mais je n'ai pas la même avis. Il est tout à fait possible de vivre (très) correctement en ne faisant que du développement OpenSource.
Produire du libre, contribuer est un moyen de gagner de l'argent, mais c'est un moyen indirect. Ce qu'on vend, ce sont
des services et des développements propriétaires. Rarement des développements libres. Ca arrive, mais ça ne suffit pas
pour vivre.
Sur Tracim, par exemple, on va gagner de l'argent en proposant des développements sur mesure, des co-développements,
des prestations d'hébergement et de service.
Sur les développements spécifiques ou sur mesure, on va gagner de l'argent en vendant des jours/homme de
développement. Le code produit sera en règle général propriétaire et deviendra la propriété de nos clients.
Mon expérience, que je retrouve dans pas mal d'autres structures similaires, diffère complètement.
Ces structures sont largement sollicitées pour développer du code source dans le cœur de logiciels. Que ce soit pour des organismes publics ou pour des organismes privés. Et parfois on a même dans les contrats ( écrits par le client) une prime si c'est bien reversé upstream, pour garantir la pérennité et la qualité des dévs.
Dans ce contexte, la contractualisation suit le droit des contrats, c'est à dire que le développeur garde le droit d'auteur et le donneur d'ordre ( et financeur ) bénéficie des droits patrimoniaux sur le code développé. Par contre on y ajoute une clause pour que tout le code source produit soit sous licence libre.
Pour une commande donnée, on va essayer de séparer ce qui est générique du spécifique. Pour le code générique, on commite directement sur les composants upstream ( ou on crée un produit libre). Pour le spécifique, on garde la clause de licence opensource, par contre le résultat n'est pas forcément toujours distribué. Mais on peut s'en resservir si on veut, au moins en interne, et dès lors qu'on s'en ressert on améliore la généricité et on va vers la publication.
Quand un client demande fermement un outil propriétaire, le crédo est souvent de refuser tout simplement, ou alors accepter à des tarifs qui sont complètement prohibitifs ( qui en gros permettraient de redévelopper le tout en opensource dans un second temps…).
Ensuite ces structures vendent du service, et la marge permet de faire du financement de R&D sur des aspects plus prospectifs.
Globalement le marché français sur l'OpenSource est assez mature, et les clients comprennent bien les enjeux socio-économiques liés au libre, et savent que c'est dans leur intérêt de reverser.
Et en ce moment, il y a plutôt un déficit de développeurs OpenSource compétents qu'une crise économique dans l'écosystème que je peux cotoyer. Rappelons que le marché Français IT a toujours eu au moins 10% de croissance au plus fort de la crise, que le marché OpenSource c'est entre 10 et 30% et que certains domaines ( SIG pour ne pas les citer) sont également dans le haut de ces chiffres.
D'autres part, on voit apparaître de nouveaux acteurs, qui sont plutot orientés SaaS et éditeurs, et qui font de très fortes contributions libres. Leur plateforme ne l'est souvent pas ( scripts d'intégration, archi..), mais toutes les composants ou presque le sont. On peut citer CartoDB ou MapBox dans le domaine carto. Ils démontrent qu'on peut tout à fait faire de grosses contributions en libre tout en étant dans un modèle économique de startup champignon ( cf les séries de levées de fond des pré-cités).
Donc l'obligation de faire du logiciel propriétaire, je ne suis pas d'accord. C'est une question de positionnement principalement. Ça ne me dérange d'ailleurs pas outre mesure si c'est un choix, mais je trouve dommage que ce soit une position subie.
À noter que l'IGN a contribué dans une modeste mesure au financement de QGIS, et supporte l'OSGeo et les logiciels libres en géomatique. Ils accueillent d'ailleurs le FOSS4G-FR à l'ENSG le mois prochain.
Je ne pense pas que PostGIS et QGIS soient tant des marchés de niche non plus, le spatial est complètement transversal, et peut bénéficier à quasiment tous les domaines de l'IT. C'est là où le libre a une carte à jouer, en mettant l'accent sur la souplesse, la capacité d'adaptation et l'interopérabilité.
Pour les mesh, on parle d'objets mesh ( pas de mesh terrain par exemple), et ils peuvent être chargés au fur et à mesure selon leur emplacement ( leur centroide X,Y par exemple). Dans la démo tout est chargé directement.
On travaille actuellement sur un chargement des objets 3D depuis du PostGIS d'après un système d'indexation et tuilage qui peut être paramétré, pour faire un chargement avec une fonction de coût personnalisée ( batiments remarquables, ou "gros" en premier par exemple). Dans ce cas nous développons nous-même la partie serveur.
Pour les points, dans iTowns on utilise un découpage en fichiers .PLY suivant la dimension temporelle, et on charge ceux qui sont corrélés aux images à l'emplacement où on se trouve. C'est simple et efficace pour les données Stéréopolis car les prises de vue sont simultanées.
Dans un cas plus général, on est en train de voir si on peut se coupler avec PoTree, qui est basé sur THREE.js également, et qui utilise un découpage des points en octree sur disque servi en HTTP.
Il y a aussi des projets comme GreyHound, qui implémente un réel serveur de streaming de points multidimensionnel.
Tout ceci n'est pas encore standardisé, mais l'OGC a démarré récemment un Working Group sur le sujet PointCloud.
Et ça fera partie des thématiques abordées cette semaine au codesprint de l'OSGeo qui a lieu chez Mozilla. Il y a une soirée ouverte le 24, n'hésitez pas à venir en discuter avec les devs !
iTowns concerne la production de logiciels, pas de données. Le jeu de donnée fourni par l'IGN, effectivement non-libre, ne sert qu'à des fins de démonstration. Vu la taille de la zone en question, l'intérêt de le mettre en libre est proche de zéro.
De plus, le jeu de données est issu du véhicule Stereopolis, qui est est la plateforme de recherche de l'IGN pour les acquisition type "Street View". Il s'agit donc de données de recherche, et pas de données de production. L'IGN ne fait pas (encore) de production pour ce type de données. Il n'y a donc pas vraiment d'enjeu à ce stade de discuter de licence sur la data.
Ensuite, le débat sur les licences de données IGN, le lien avec OSM, le modèle économique de l'Institut, ça fait déjà un moment qu'il existe et il n'est pas simple. Il y a de multiples articles et prises de position à ce sujet sur le net, assez faciles à trouver. Et on notera tout de même que les choses ont avancé sur divers sujets, notamment la BANO.
Pour ce qui est de "le logiciel sans contenu ne sert à rien", c'est tout simplement faux. Si on regarde les types de données supportées par iTowns, on se rend compte qu'on peut tout à fait produire ses propres données, par exemple :
Avec des photos et de la photogrammétrie ( -> images orientées, nuages de points), avec prise de vue manuelle, drone, avion…
Vectoriel 2D à partir de n'importe quelle source SIG, y compris des données OSM
Meshes 3D : avec n'importe quel logiciel produisant du 3DS, ou avec de la reconstruction automatique
Nuages de points : par photogrammétrie ou avec un capteur LIDAR ( terrestre ou aéroporté)
Panoramas : avec des appareils photos classique et des outils idoines, ou des capteurs type "Ladybug"
La production de ces données n'est pas forcément simple, les workflows peuvent être complexes, mais ce n'est pas l'objet du logiciel en question, qui est par ailleurs orienté vers une mise en place par des personnes du métier ( photogrammétrie, LIDAR, SIG, 3D).
Mais c'est bien l'intérêt du framework de pouvoir être utilisé avec d'autres données que celles de l'IGN. Il reste encore des efforts à faire en développement pour le rendre encore plus générique, mais c'est en cours.
C'est donc tout à fait utilisable "dans OpenStreetMap" si tant est que cela veuille dire quelque chose.
Concernant les logiciels libres de façon générale, l'IGN a bien une démarche en ce sens, utilisé et intègre des composants libres dans ses architectures, en production, en recherche et en enseignement ( PostGIS, QGIS, GeoServer…). L'institut finance donc directement et indirectement des projets. et produit un certain nombre d'outils en propre :
On peut citer MicMac, Rok4, des contributions dans PostGIS…
Alors oui, on peut être éternellement déçu, mais je pense qu'il faut savoir reconnaître les avancées et les initiative vers le libre quand elles sont avérée.
L'opération que tu souhaites faire, transformer une addresse littérale du type "10 rue des lilas, 13001 Marseille", en des coordonnées de points géographiques ( latitude, longitude par exemple), s'appelle le géocodage.
C'est une étape initiale nécessaire pour pouvoir exploiter ensuite ces informations sous forme de données géographiques si tu n'as que cette information d'adresse littérale.
Cette opération de géocodage n'est pas simple, et elle nécessite d'avoir une base de données d'adresse de référence pour pouvoir faire le rapprochement. Si tu n'en as pas, tu peux utiliser des services en ligne qui proposent des fonctionnalités de géocodage.
L'API Google Maps permet de le faire (avec des restrictions d'usage). Tu peux aussi utiliser le géocodeur lié à BANO qui permet de géocoder du CSV : http://adresse.data.gouv.fr/csv/
Il y a d'autres géocodeurs existant, avec des qualités variables et des contraintes variables aussi.
Dans tous les cas, attention de bien lire les conditions d'utilisation des résultats et les contraintes de licence.
Si tu connais le code insee de chaque adresse, tu peux aussi télécharger le GEOFLA IGN (ou les limites de commune OpenStreetMap) avec leurs géométries polygonales, faire une jointure attributaire sur le code insee, et travailler à ce niveau de détail.
Pour tout ce qui est traitement de données géographiques (et attributaires), je ne peux que te conseiller d'oublier MySQL et de passer à PostgreSQL / PostGIS, que tu pourras exploiter au maximum avec QGIS pour la visualisation.
Merci pour les précisions, ça répond bien aux questions.
Pour la question de la licence, c'est effectivement complexe, et certainement dans la zone grise de l'ODbL. Encore une démonstration du besoin de passage d'OSM en domaine public (Troll inside).
Pour les données GTFS, la question se pose aussi, ça dépend des licences des différentes données.
Intéressé pour avoir les résultats si une étude juridique complète est faite à ce sujet (c'est certainement Benjamin Jean le mieux placé pour éclairer sur ces sujets).
Bravo pour la libération et la démarche d'ouverture tout d'abord !
Quelques questions :
Est-ce réellement un calculateur d'itinéraires multimodal, ou juste TC + piéton en complément du TC ?
Si c'est multimodal, est ce que la multimodalité est intégrée dans la définition du graphe de réseau ou dans les algorithmes utilisés ?
Est ce que l'optimisation d'itinéraire tient compte des horaires de passage ? (à priori oui). Dans ce cas même question, est ce fait en démultipliant le graphe de réseau selon les horaires de passage ou c'est l'algorithme RAPTOR qui permet de tenir compte du temporel ?
Quel est le framework Python utilisé ?
Si vous mélangez de la donnée GTFS et de la donnée OSM, comment gérez vous les potentielles incompatibilités de licence sur la création des itinéraires de résultat entre l'ODbL ("share-alike") et une licence GTFS qui empêcherait le SA ?
OSRM n'est pas cité dans les autres calculateurs, est ce que c'est parce qu'il est d'abord orienté routier ?
Dans tous les cas PostgreSQL 8.2 n'est plus supporté, et les différences entre PG 8.3 et 8.4 font qu'il est très fortement conseillé d'utiliser cette dernière si on veut rester dans la version majeure 8.
Globalement avec PostgreSQL, on a toujours intérêt à utiliser la dernière version stable (sauf contraintes spécifiques bien sur, organisationnelle, de dépendance…).
Oui, en fait on utilise indifféremment pour PostGIS «cartouche spatiale», «extension spatiale», «plugin» ou «module». C'est certainement le terme d'extension qui restera à terme, vu que c'est comme cela que s'appelle le mécanisme technique implémenté dans PostgreSQL 9.1.
Exemple :
J'ai une table de communes (représentées par des polygones), et une table avec des points représentant les endroits où on trouve des services (médecin, pharmacie, etc). Ces deux tables n'ont aucun identifiant commun permettant de les relier par une jointure alphanumérique.
Je peux alors faire des requêtes SQL spatiales pour répondre à une question par exemple :
«combien y a t-il de médecins par commune et quelle est leur zone de couverture ?»
Si je simplifie et considère qu'un médecin couvre une zone de 3 kilomètres à vol d'oiseau autour de son implantation, je peux effectuer la requête suivante :
select
c.code_insee
, c.name
, count(*) as nb
, st_asgeojson(st_concave_hull(st_union(st_buffer(s.geom, 3000), 0.99, true)) as zone_couverture
from
communes as c
join
services as s
on
st_contains(c.geom, s.geom)
where
s.type = 'medecin'
group by
c.code_insee, c.name;
Je vais alors récupérer une liste de communes, avec le nombre de médecins dans chaque commune, et un objet géométrique (ici au format geojson), qui représente la zone de couverture globale des médecins dans la commune. Je peux ensuite renvoyer les résultats à une application cliente web utilisant OpenLayers par exemple, et afficher le tout sur une carte.
Les géométries sont traitées de la même façon que les objets classiques de la base de données, et les possibilités de traitement et d'analyse sont tout aussi étendues.
C'est le terme qui est utilisé en géomatique pour désigner l'extension d'une base de données qui permet de traiter l'information géographique.
Selon moi, cela ne vient pas de l'anglais, mais d'une déformation d'usage d'un nom masculin français, «LE cartouche».
Selon le Grand Dictionnaire Terminologique, le cartouche en géographie est :
Encadrement figurant au bas d'un tableau ou d'une carte géographique, dans lequel sont indiqués le titre, la légende ou d'autres mentions.
Par analogie de construction, le cartouche spatial d'une base de donnée, est donc un élément positionné sur la base de données, rajoutant des éléments supplémentaires, en l’occurrence des éléments géographiques.
C'est mon opinion personnelle, mais je n'ai jamais trouvé d'autre explication. En tout cas loin de l'idée des développeurs de PostGIS d'introduire une quelconque violence dans leur logiciel :)
Il s'agit principalement de la réécriture du format de sérialisation interne des géométries, ainsi que de la réécriture d'une grande partie du code d'indexation.
Le parser (WKT & co) a également bénéficié de petits soins lui donnant plus de robustesse.
On trouve aussi plus de fonctions qui supportent le type geography que dans la 1.5.3.
La gestion des géométries EMPTY a également été rationalisée.
Ensuite on trouve des corrections de bug en pagaille.
(je me permets de remettre ce message ici puisque le journal est passé dépêche).
A noter que l'OSGeo, association qui chapeaute les projets libres dans le domaine des systèmes d'information géographique a été sélectionnée comme organisation pour le GSoC 2012.
Nous recherchons des étudiants pour participer aux projets proposés (ou le votre).
A noter que l'OSGeo, association qui chapeaute les projets libres dans le domaine des systèmes d'information géographique a été sélectionnée comme organisation pour le GSoC 2012.
Nous recherchons des étudiants pour participer aux projets proposés (ou le votre).
Salut,
Ayant fait le passage au bépo il y a maintenant 3 ans, je ne peux qu'appuyer chacun des points soulevés, y compris les problèmes de canal carpiens résolus.
Avec l'intégration du layout dans les distributions, et le petit driver portable windows, c'est un plaisir de l'utiliser sur n'importe quelle machine, y compris celles avec des claviers exotiques, en tapant à l'aveugle.
Bépo c'est bon, mangez en !
Personnellement je suis pour une licence type LGPL pour OSM. Les modifications de la base de données OSM reste libre et on peut lier des choses non libres avec.
Je suis bien d'accord. Cependant aujourd'hui ce n'est pas le cas, le SA de la CC, appliqué au données fait qu'on ne peut rien lier de non libre avec. Et c'est bien le coeur du problème.
Le problème de Mappy c'est son discours qui laisse entendre que le reversement à la communauté est impossible : « nous n'avons pas l'intention de faire don de nos POI ». Or je suis sûr qu'en prenant contact avec la communauté il serait possible de faire des milliers de choses…
Avec la licence actuelle malheureusement c'est très difficile pour les acteurs privés de collaborer avec OSM.
De plus, la communication de Mappy en l'occurrence est ratée sur ce point. Ce n'est pas une raison pour leur faire un procès d'intention. A nous aussi de faire un pas vers eux, histoire d'aller de l'avant et de favoriser la création et le développement de l'écosystème des données libres plutot que de se perdre en affrontements stériles.
Premièrement le «c'est lui qui a commencé» comme argument on a fait mieux coté éducation.
Et pourquoi Mappy ne commencerait-il pas à dire qu'il pourrait contribuer?
" nous ne sommes pas certains que l'on puisse utiliser des données OSM sans que les points d'intérêt que nous y plaçons ne tombent pas dans le domaine public"
Pour moi, cette phrase indique clairement que l'OSM gratuit est très intéressant, mais que Mappy ne voit pas pourquoi il offrirai quelque chose en échange si ils n'en sont pas contraints (ou que si ils y sont contraints, il préfèrent se passer d'OSM).
Qui commence avec une mauvaise image?
Il cite le point bloquant pour eux : leur base de POI c'est leur coeur de métier, ils ne peuvent pas la libérer car ça remet en cause tout leur modèle économique. Je ne dis pas que c'est une mauvaise chose dans l'absolu, mais restons réaliste, une boite comme ça ne change pas de modèle économique en claquant des doigts, ça prend plutot 10 ans.
Ce qui ne veut pas dire que sur d'autres données, comme la la donnée de base de réseau routier par exemple, ils ne sont pas prêts à collaborer.
Ensuite il y a la question des POI (Points d'intérêts). Mappy est intéressé par la gratuité de la carte mais ne veut en aucun cas contribuer à son amélioration. Il refuse le modèle du libre pour se tourner vers un modèle à un seul sens, ne retenant que la gratuité d'OSM.
Ça c'est ton interprétation personnelle. Mappy dit juste qu'il ne veut pas libérer sa base de POI. Ça ne veut en aucun cas dire qu'ils ne veulent pas contribuer, qu'ils ne sont pas prêts à collaborer, qu'ils refusent le modèle du libre.
Cependant pour admettre ça il faudrait sortir du manichéisme, avec les bons libres d'un coté et les mauvais pilleurs du libre de l'autre. La réalité du libre en entreprise est tout autre, et souvent un savant mélange de l'un et de l'autre. Et ça profite au libre en général.
C'est pas en refusant en bloc les gens qui s'intéressent à OSM commercialement qu'on fera avancer les choses et qu'on les convaincra de participer et de contribuer. On se croirait dans les discours sur le logiciel libre d'il y a 10 ans !
Surtout que 70 000 hôtels paraissent risibles s'il y a juste des adresses. Il est fort à parier quand quelques années les contributeurs d'OSM remplissent la base de ces données. Si il y aussi le prix d'une chambre simple/double c'est tout autre, ils peuvent mettre les POI dans OSM et faire un lien vers une base de données à eux qui aura toutes les informations à forte valeur ajouté.
Sauf qu'a partir du moment où ils voudront exploiter ces données liées, ils devront faire une «jointure» entre les données OSM et les données de POI, et ils tomberont sous le coup de la clause SA car ce sera considéré comme un produit dérivé. Donc non c'est pas possible à priori, en tout cas selon mon interprétation de la licence CC-By-SA sur les données. Je ne demande qu'a être contredit par un juriste, ce sera avec plaisir.
La notion de produit dérivé sur les données est tellement floue que la plupart des boites qui s'intéressent à OSM soit le pillent completement en douce, soit font demi tour devant les problèmes juridiques et techniques que cette notion induit.
Je trouve que le procès fait à Mappy relève plus d'une réaction épidermique contre l'arrivée des entreprises dans le monde de la donnée libre que d'une réelle analyse des tenants et des aboutissants. Ça ne donne pas une très bonne image de la communauté. Pourquoi ne pas plutot engager un dialogue qui amènera à de la collaboration ?
Depuis que j'avais vu la présentation de Damian Conway (perl guru), «Geek Eye for the Suit Guy», qui utilisait ce principe, j'avais voulu me lancer dans ce type de présentation. Mais sans outil libre adéquat ce n'était pas vraiment faisable.
Enfin un logiciel qui ouvre de nouvelles perspectives donc !
La démo rame un petit peu, et on peut se dire que plus on complexifie l'animation plus ça risque de ralentir non ? Il serait possible d'envisager des exports vers d'autres formats ? Voire carrément générer des vidéos ?
Ou bien est ce qu'il y a des lecteurs SVG plus efficaces que firefox ?
Et dans le genre video/présentation animée, celle ci est au top :
Si on pouvait avoir un soft qui permet simplement de faire ce genre d'animations ce serait vraiment chouette. Bon ok, ça demande également du talent graphique, certes.
# Autre réaction, liens et complément réaction Debian
Posté par Vincent P (site web personnel) . En réponse à la dépêche Cybersécurité - le texte du CRA a été finalisé. Évalué à 5.
L'OSGeo a publié également une réaction au texte final, incluant plusieurs liens intéressants :
https://www.osgeo.org/foundation-news/eu-cyber-resilience-act-information-update/
Ils notent en particulier que la réaction de Debian, qui est mentionnée également dans les liens de cet article LinuxFR, a été faite juste après la publication du texte final du CRA et ne prend pas en compte à priori certains éléments, rendant l'analyse pas totalement juste.
Ils pointent vers une analyse plus récente et complète également :
https://berthub.eu/articles/posts/eu-cra-what-does-it-mean-for-open-source/
Clairement, il va falloir un peu de temps pour bien comprendre les implications pour les différents types d'acteurs de l'écosystème. Il semble à première vue qu'on est pas sur la catastrophe du texte initial, mais il est également clair que ce texte aura un impact sur l'écosystème OpenSource ( mais aussi sur tout l'écosystème IT européen voire mondial ). Il y a des points positifs et d'autres qui le sont moins, les lignes vont bouger, il faudra savoir s'adapter au mieux.
Ce serait intéressant que le CNLL finance une étude un peu approfondie pour clarifier les impacts pour les communautés de développeurs, les fondations, et les différents types d'entreprises du libre ( intégrateurs, éditeurs, ENL/SSLL… ), ainsi que les actions à mettre en place.
# témoignage de Vladimir Agafonkin
Posté par Vincent P (site web personnel) . En réponse au journal Leafletjs - l'auteur Vladimir Agafonkin vie à Kiev. Évalué à 2.
Vladimir témoigne de la situation sur un live ici :
https://twitter.com/MapScaping/status/1500789168120770562
Et également ici :
https://news.ycombinator.com/item?id=30551006
# Similaire : projet Phoniebox
Posté par Vincent P (site web personnel) . En réponse au journal Faire son propre JukeBox avec un Raspberry Pi. Évalué à 2.
Dans la même veine pour les petits, il y a le projet PhonieBox : un assemblage sans soudure avec un Raspberry Pi. En terme d'interface ce sont des cartes RFID ( ou des puces à coller sur des objets ) qu'on peut associer à des albums.
Des exemples :
# Expérience qui diffère : on peut vivre du libre à 100% !
Posté par Vincent P (site web personnel) . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 5.
Salut,
Je ne sais pas bien dans quel contexte tu travailles, mais je n'ai pas la même avis. Il est tout à fait possible de vivre (très) correctement en ne faisant que du développement OpenSource.
Mon expérience, que je retrouve dans pas mal d'autres structures similaires, diffère complètement.
Ces structures sont largement sollicitées pour développer du code source dans le cœur de logiciels. Que ce soit pour des organismes publics ou pour des organismes privés. Et parfois on a même dans les contrats ( écrits par le client) une prime si c'est bien reversé upstream, pour garantir la pérennité et la qualité des dévs.
Dans ce contexte, la contractualisation suit le droit des contrats, c'est à dire que le développeur garde le droit d'auteur et le donneur d'ordre ( et financeur ) bénéficie des droits patrimoniaux sur le code développé. Par contre on y ajoute une clause pour que tout le code source produit soit sous licence libre.
Pour une commande donnée, on va essayer de séparer ce qui est générique du spécifique. Pour le code générique, on commite directement sur les composants upstream ( ou on crée un produit libre). Pour le spécifique, on garde la clause de licence opensource, par contre le résultat n'est pas forcément toujours distribué. Mais on peut s'en resservir si on veut, au moins en interne, et dès lors qu'on s'en ressert on améliore la généricité et on va vers la publication.
Quand un client demande fermement un outil propriétaire, le crédo est souvent de refuser tout simplement, ou alors accepter à des tarifs qui sont complètement prohibitifs ( qui en gros permettraient de redévelopper le tout en opensource dans un second temps…).
Ensuite ces structures vendent du service, et la marge permet de faire du financement de R&D sur des aspects plus prospectifs.
Globalement le marché français sur l'OpenSource est assez mature, et les clients comprennent bien les enjeux socio-économiques liés au libre, et savent que c'est dans leur intérêt de reverser.
Et en ce moment, il y a plutôt un déficit de développeurs OpenSource compétents qu'une crise économique dans l'écosystème que je peux cotoyer. Rappelons que le marché Français IT a toujours eu au moins 10% de croissance au plus fort de la crise, que le marché OpenSource c'est entre 10 et 30% et que certains domaines ( SIG pour ne pas les citer) sont également dans le haut de ces chiffres.
D'autres part, on voit apparaître de nouveaux acteurs, qui sont plutot orientés SaaS et éditeurs, et qui font de très fortes contributions libres. Leur plateforme ne l'est souvent pas ( scripts d'intégration, archi..), mais toutes les composants ou presque le sont. On peut citer CartoDB ou MapBox dans le domaine carto. Ils démontrent qu'on peut tout à fait faire de grosses contributions en libre tout en étant dans un modèle économique de startup champignon ( cf les séries de levées de fond des pré-cités).
Donc l'obligation de faire du logiciel propriétaire, je ne suis pas d'accord. C'est une question de positionnement principalement. Ça ne me dérange d'ailleurs pas outre mesure si c'est un choix, mais je trouve dommage que ce soit une position subie.
[^] # Re: Franchir un seuil critique
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de QGIS 2.14 LTR « Essen ». Évalué à 5.
À noter que l'IGN a contribué dans une modeste mesure au financement de QGIS, et supporte l'OSGeo et les logiciels libres en géomatique. Ils accueillent d'ailleurs le FOSS4G-FR à l'ENSG le mois prochain.
Je ne pense pas que PostGIS et QGIS soient tant des marchés de niche non plus, le spatial est complètement transversal, et peut bénéficier à quasiment tous les domaines de l'IT. C'est là où le libre a une carte à jouer, en mettant l'accent sur la souplesse, la capacité d'adaptation et l'interopérabilité.
[^] # Re: tiens l'IGN essaie de faire du libre ?
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de iTowns v1.0 : framework web pour la donnée géographique 3D . Évalué à 2.
Si on regarde là, il y a tout de même pas mal de données qui sont déjà gratuites (pas toutes forcément libre) :
On y retrouve notamment Litto3D avec le SHOM, une couverture LIDAR de toutes les côtes françaises.
Et la BANO qui n'y est pas mentionnée.
[^] # Re: Streaming
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de iTowns v1.0 : framework web pour la donnée géographique 3D . Évalué à 2.
Salut,
Ça dépend un peu de ce que tu appelles streaming.
Pour les mesh, on parle d'objets mesh ( pas de mesh terrain par exemple), et ils peuvent être chargés au fur et à mesure selon leur emplacement ( leur centroide X,Y par exemple). Dans la démo tout est chargé directement.
On travaille actuellement sur un chargement des objets 3D depuis du PostGIS d'après un système d'indexation et tuilage qui peut être paramétré, pour faire un chargement avec une fonction de coût personnalisée ( batiments remarquables, ou "gros" en premier par exemple). Dans ce cas nous développons nous-même la partie serveur.
https://github.com/Oslandia/building-server
Pour les points, dans iTowns on utilise un découpage en fichiers .PLY suivant la dimension temporelle, et on charge ceux qui sont corrélés aux images à l'emplacement où on se trouve. C'est simple et efficace pour les données Stéréopolis car les prises de vue sont simultanées.
Dans un cas plus général, on est en train de voir si on peut se coupler avec PoTree, qui est basé sur THREE.js également, et qui utilise un découpage des points en octree sur disque servi en HTTP.
Il y a aussi des projets comme GreyHound, qui implémente un réel serveur de streaming de points multidimensionnel.
Tout ceci n'est pas encore standardisé, mais l'OGC a démarré récemment un Working Group sur le sujet PointCloud.
Et ça fera partie des thématiques abordées cette semaine au codesprint de l'OSGeo qui a lieu chez Mozilla. Il y a une soirée ouverte le 24, n'hésitez pas à venir en discuter avec les devs !
[^] # Re: tiens l'IGN essaie de faire du libre ?
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de iTowns v1.0 : framework web pour la donnée géographique 3D . Évalué à 10.
Salut,
iTowns concerne la production de logiciels, pas de données. Le jeu de donnée fourni par l'IGN, effectivement non-libre, ne sert qu'à des fins de démonstration. Vu la taille de la zone en question, l'intérêt de le mettre en libre est proche de zéro.
De plus, le jeu de données est issu du véhicule Stereopolis, qui est est la plateforme de recherche de l'IGN pour les acquisition type "Street View". Il s'agit donc de données de recherche, et pas de données de production. L'IGN ne fait pas (encore) de production pour ce type de données. Il n'y a donc pas vraiment d'enjeu à ce stade de discuter de licence sur la data.
Ensuite, le débat sur les licences de données IGN, le lien avec OSM, le modèle économique de l'Institut, ça fait déjà un moment qu'il existe et il n'est pas simple. Il y a de multiples articles et prises de position à ce sujet sur le net, assez faciles à trouver. Et on notera tout de même que les choses ont avancé sur divers sujets, notamment la BANO.
Pour ce qui est de "le logiciel sans contenu ne sert à rien", c'est tout simplement faux. Si on regarde les types de données supportées par iTowns, on se rend compte qu'on peut tout à fait produire ses propres données, par exemple :
La production de ces données n'est pas forcément simple, les workflows peuvent être complexes, mais ce n'est pas l'objet du logiciel en question, qui est par ailleurs orienté vers une mise en place par des personnes du métier ( photogrammétrie, LIDAR, SIG, 3D).
Mais c'est bien l'intérêt du framework de pouvoir être utilisé avec d'autres données que celles de l'IGN. Il reste encore des efforts à faire en développement pour le rendre encore plus générique, mais c'est en cours.
C'est donc tout à fait utilisable "dans OpenStreetMap" si tant est que cela veuille dire quelque chose.
Concernant les logiciels libres de façon générale, l'IGN a bien une démarche en ce sens, utilisé et intègre des composants libres dans ses architectures, en production, en recherche et en enseignement ( PostGIS, QGIS, GeoServer…). L'institut finance donc directement et indirectement des projets. et produit un certain nombre d'outils en propre :
On peut citer MicMac, Rok4, des contributions dans PostGIS…
Alors oui, on peut être éternellement déçu, mais je pense qu'il faut savoir reconnaître les avancées et les initiative vers le libre quand elles sont avérée.
[^] # Re: Petite question d'un débutant
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de QGIS 2.10 « Pisa ». Évalué à 10.
Salut Paul,
L'opération que tu souhaites faire, transformer une addresse littérale du type "10 rue des lilas, 13001 Marseille", en des coordonnées de points géographiques ( latitude, longitude par exemple), s'appelle le géocodage.
C'est une étape initiale nécessaire pour pouvoir exploiter ensuite ces informations sous forme de données géographiques si tu n'as que cette information d'adresse littérale.
Cette opération de géocodage n'est pas simple, et elle nécessite d'avoir une base de données d'adresse de référence pour pouvoir faire le rapprochement. Si tu n'en as pas, tu peux utiliser des services en ligne qui proposent des fonctionnalités de géocodage.
L'API Google Maps permet de le faire (avec des restrictions d'usage). Tu peux aussi utiliser le géocodeur lié à BANO qui permet de géocoder du CSV : http://adresse.data.gouv.fr/csv/
Il y a d'autres géocodeurs existant, avec des qualités variables et des contraintes variables aussi.
Dans tous les cas, attention de bien lire les conditions d'utilisation des résultats et les contraintes de licence.
Si tu connais le code insee de chaque adresse, tu peux aussi télécharger le GEOFLA IGN (ou les limites de commune OpenStreetMap) avec leurs géométries polygonales, faire une jointure attributaire sur le code insee, et travailler à ce niveau de détail.
Pour tout ce qui est traitement de données géographiques (et attributaires), je ne peux que te conseiller d'oublier MySQL et de passer à PostgreSQL / PostGIS, que tu pourras exploiter au maximum avec QGIS pour la visualisation.
[^] # Re: Multimodal et autres questions
Posté par Vincent P (site web personnel) . En réponse à la dépêche Libération de navitia : un calculateur d’itinéraire pour les transports en communs. Évalué à 1.
Merci pour les précisions, ça répond bien aux questions.
Pour la question de la licence, c'est effectivement complexe, et certainement dans la zone grise de l'ODbL. Encore une démonstration du besoin de passage d'OSM en domaine public (Troll inside).
Pour les données GTFS, la question se pose aussi, ça dépend des licences des différentes données.
Intéressé pour avoir les résultats si une étude juridique complète est faite à ce sujet (c'est certainement Benjamin Jean le mieux placé pour éclairer sur ces sujets).
# Multimodal et autres questions
Posté par Vincent P (site web personnel) . En réponse à la dépêche Libération de navitia : un calculateur d’itinéraire pour les transports en communs. Évalué à 7.
Bonjour,
Bravo pour la libération et la démarche d'ouverture tout d'abord !
Quelques questions :
Merci pour les précisions !
[^] # Re: Petite précision
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de PostGIS 2.0. Évalué à 2.
Dans tous les cas PostgreSQL 8.2 n'est plus supporté, et les différences entre PG 8.3 et 8.4 font qu'il est très fortement conseillé d'utiliser cette dernière si on veut rester dans la version majeure 8.
Globalement avec PostgreSQL, on a toujours intérêt à utiliser la dernière version stable (sauf contraintes spécifiques bien sur, organisationnelle, de dépendance…).
[^] # Re: I beg your pardon?
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de PostGIS 2.0. Évalué à 3.
Oui, en fait on utilise indifféremment pour PostGIS «cartouche spatiale», «extension spatiale», «plugin» ou «module». C'est certainement le terme d'extension qui restera à terme, vu que c'est comme cela que s'appelle le mécanisme technique implémenté dans PostgreSQL 9.1.
[^] # Re: I beg your pardon?
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de PostGIS 2.0. Évalué à 10.
Exemple :
J'ai une table de communes (représentées par des polygones), et une table avec des points représentant les endroits où on trouve des services (médecin, pharmacie, etc). Ces deux tables n'ont aucun identifiant commun permettant de les relier par une jointure alphanumérique.
Je peux alors faire des requêtes SQL spatiales pour répondre à une question par exemple :
«combien y a t-il de médecins par commune et quelle est leur zone de couverture ?»
Si je simplifie et considère qu'un médecin couvre une zone de 3 kilomètres à vol d'oiseau autour de son implantation, je peux effectuer la requête suivante :
Je vais alors récupérer une liste de communes, avec le nombre de médecins dans chaque commune, et un objet géométrique (ici au format geojson), qui représente la zone de couverture globale des médecins dans la commune. Je peux ensuite renvoyer les résultats à une application cliente web utilisant OpenLayers par exemple, et afficher le tout sur une carte.
Les géométries sont traitées de la même façon que les objets classiques de la base de données, et les possibilités de traitement et d'analyse sont tout aussi étendues.
[^] # Re: I beg your pardon?
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de PostGIS 2.0. Évalué à 10.
C'est une bonne question !
C'est le terme qui est utilisé en géomatique pour désigner l'extension d'une base de données qui permet de traiter l'information géographique.
Selon moi, cela ne vient pas de l'anglais, mais d'une déformation d'usage d'un nom masculin français, «LE cartouche».
Selon le Grand Dictionnaire Terminologique, le cartouche en géographie est :
Par analogie de construction, le cartouche spatial d'une base de donnée, est donc un élément positionné sur la base de données, rajoutant des éléments supplémentaires, en l’occurrence des éléments géographiques.
C'est mon opinion personnelle, mais je n'ai jamais trouvé d'autre explication. En tout cas loin de l'idée des développeurs de PostGIS d'introduire une quelconque violence dans leur logiciel :)
[^] # Re: où ça des améliorations ?
Posté par Vincent P (site web personnel) . En réponse à la dépêche Sortie de PostGIS 2.0. Évalué à 5.
Il s'agit principalement de la réécriture du format de sérialisation interne des géométries, ainsi que de la réécriture d'une grande partie du code d'indexation.
Le parser (WKT & co) a également bénéficié de petits soins lui donnant plus de robustesse.
On trouve aussi plus de fonctions qui supportent le type geography que dans la 1.5.3.
La gestion des géométries EMPTY a également été rationalisée.
Ensuite on trouve des corrections de bug en pagaille.
Pour plus d'info il faut aller voir le changelog ou bien le trac. Par exemple :
http://svn.osgeo.org/postgis/trunk/ChangeLog
http://trac.osgeo.org/postgis/query
# L'OSGeo cherche des étudiants
Posté par Vincent P (site web personnel) . En réponse à la dépêche Début du Google Summer of Code 2012. Évalué à 4.
Bonjour,
(je me permets de remettre ce message ici puisque le journal est passé dépêche).
A noter que l'OSGeo, association qui chapeaute les projets libres dans le domaine des systèmes d'information géographique a été sélectionnée comme organisation pour le GSoC 2012.
Nous recherchons des étudiants pour participer aux projets proposés (ou le votre).
Une liste des projets possible est disponible ici :
http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012_Ideas
Par exemple pour le projet MapServer :
http://wiki.osgeo.org/wiki/MapServer_2012_SOC_Ideas
N'hésitez pas à vous renseigner et proposer votre candidature, sur les mailings list du projet concerné, ou bien sur la liste du GSoC de l'OSGeo, ou la liste francophone :
http://lists.osgeo.org/mailman/listinfo/francophone
http://lists.osgeo.org/mailman/listinfo/soc
Ne tardez pas, les candidatures sont ouvertes jusqu'au 6 avril et il y a un dossier à monter.
Les projets dans le domaine des SIG sont en général assez sympas, et c'est un secteur en pleine croissance, avec des outils libres très intéressants.
On me glisse également que PostgreSQL cherche également des étudiants :
http://www.postgresql.org/developer/summerofcode/
A vous !
# L'OSGeo cherche des étudiants
Posté par Vincent P (site web personnel) . En réponse au journal Début du Google Summer of Code 2012. Évalué à 5.
Bonjour,
A noter que l'OSGeo, association qui chapeaute les projets libres dans le domaine des systèmes d'information géographique a été sélectionnée comme organisation pour le GSoC 2012.
Nous recherchons des étudiants pour participer aux projets proposés (ou le votre).
Une liste des projets possible est disponible ici :
http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2012_Ideas
Par exemple pour le projet MapServer :
http://wiki.osgeo.org/wiki/MapServer_2012_SOC_Ideas
N'hésitez pas à vous renseigner et proposer votre candidature, sur les mailings list du projet concerné, ou bien sur la liste du GSoC de l'OSGeo, ou la liste francophone :
http://lists.osgeo.org/mailman/listinfo/francophone
http://lists.osgeo.org/mailman/listinfo/soc
Ne tardez pas, les candidatures sont ouvertes jusqu'au 6 avril et il y a un dossier à monter.
Les projets dans le domaine des SIG sont en général assez sympas, et c'est un secteur en pleine croissance, avec des outils libres très intéressants.
On me glisse également que PostgreSQL cherche également des étudiants :
http://www.postgresql.org/developer/summerofcode/
A vous !
# hnfkj eqk ùqo
Posté par Vincent P (site web personnel) . En réponse au sondage La disposition Bépo…. Évalué à 2.
Hnfkj ,sqmi ùyfùf kxùeq of azer kqs! ,sqmi rm kf lfjlrsuf ksl sm hoqudfl qljx rß ow hq ifudfmj uldqùfmj hrùeod,sz if jlrsufl ofk armmfk jrsh:fkv %qdk ,sfoof kqjdk!qhjdrm if ersurdl jqefl fm qufs;of fm lf;qliqmj if:rlk Y
# 100% d'accord
Posté par Vincent P (site web personnel) . En réponse au journal Adopter une bonne disposition pour 2012: passez au bépo !. Évalué à 3.
Salut,
Ayant fait le passage au bépo il y a maintenant 3 ans, je ne peux qu'appuyer chacun des points soulevés, y compris les problèmes de canal carpiens résolus.
Avec l'intégration du layout dans les distributions, et le petit driver portable windows, c'est un plaisir de l'utiliser sur n'importe quelle machine, y compris celles avec des claviers exotiques, en tapant à l'aveugle.
Bépo c'est bon, mangez en !
[^] # Re: c'est une vision biaisée
Posté par Vincent P (site web personnel) . En réponse au journal [OSM] Mappy veut bien piller mais pas contribuer. Évalué à 3.
Personnellement je suis pour une licence type LGPL pour OSM. Les modifications de la base de données OSM reste libre et on peut lier des choses non libres avec.
Je suis bien d'accord. Cependant aujourd'hui ce n'est pas le cas, le SA de la CC, appliqué au données fait qu'on ne peut rien lier de non libre avec. Et c'est bien le coeur du problème.
Le problème de Mappy c'est son discours qui laisse entendre que le reversement à la communauté est impossible : « nous n'avons pas l'intention de faire don de nos POI ». Or je suis sûr qu'en prenant contact avec la communauté il serait possible de faire des milliers de choses…
Avec la licence actuelle malheureusement c'est très difficile pour les acteurs privés de collaborer avec OSM.
De plus, la communication de Mappy en l'occurrence est ratée sur ce point. Ce n'est pas une raison pour leur faire un procès d'intention. A nous aussi de faire un pas vers eux, histoire d'aller de l'avant et de favoriser la création et le développement de l'écosystème des données libres plutot que de se perdre en affrontements stériles.
[^] # Re: c'est une vision biaisée
Posté par Vincent P (site web personnel) . En réponse au journal [OSM] Mappy veut bien piller mais pas contribuer. Évalué à 9.
Et pourquoi Mappy ne commencerait-il pas à dire qu'il pourrait contribuer?
" nous ne sommes pas certains que l'on puisse utiliser des données OSM sans que les points d'intérêt que nous y plaçons ne tombent pas dans le domaine public"
Pour moi, cette phrase indique clairement que l'OSM gratuit est très intéressant, mais que Mappy ne voit pas pourquoi il offrirai quelque chose en échange si ils n'en sont pas contraints (ou que si ils y sont contraints, il préfèrent se passer d'OSM).
Qui commence avec une mauvaise image?
Il cite le point bloquant pour eux : leur base de POI c'est leur coeur de métier, ils ne peuvent pas la libérer car ça remet en cause tout leur modèle économique. Je ne dis pas que c'est une mauvaise chose dans l'absolu, mais restons réaliste, une boite comme ça ne change pas de modèle économique en claquant des doigts, ça prend plutot 10 ans.
Ce qui ne veut pas dire que sur d'autres données, comme la la donnée de base de réseau routier par exemple, ils ne sont pas prêts à collaborer.
# c'est une vision biaisée
Posté par Vincent P (site web personnel) . En réponse au journal [OSM] Mappy veut bien piller mais pas contribuer. Évalué à 8.
Ensuite il y a la question des POI (Points d'intérêts). Mappy est intéressé par la gratuité de la carte mais ne veut en aucun cas contribuer à son amélioration. Il refuse le modèle du libre pour se tourner vers un modèle à un seul sens, ne retenant que la gratuité d'OSM.
Ça c'est ton interprétation personnelle. Mappy dit juste qu'il ne veut pas libérer sa base de POI. Ça ne veut en aucun cas dire qu'ils ne veulent pas contribuer, qu'ils ne sont pas prêts à collaborer, qu'ils refusent le modèle du libre.
Cependant pour admettre ça il faudrait sortir du manichéisme, avec les bons libres d'un coté et les mauvais pilleurs du libre de l'autre. La réalité du libre en entreprise est tout autre, et souvent un savant mélange de l'un et de l'autre. Et ça profite au libre en général.
C'est pas en refusant en bloc les gens qui s'intéressent à OSM commercialement qu'on fera avancer les choses et qu'on les convaincra de participer et de contribuer. On se croirait dans les discours sur le logiciel libre d'il y a 10 ans !
Surtout que 70 000 hôtels paraissent risibles s'il y a juste des adresses. Il est fort à parier quand quelques années les contributeurs d'OSM remplissent la base de ces données. Si il y aussi le prix d'une chambre simple/double c'est tout autre, ils peuvent mettre les POI dans OSM et faire un lien vers une base de données à eux qui aura toutes les informations à forte valeur ajouté.
Sauf qu'a partir du moment où ils voudront exploiter ces données liées, ils devront faire une «jointure» entre les données OSM et les données de POI, et ils tomberont sous le coup de la clause SA car ce sera considéré comme un produit dérivé. Donc non c'est pas possible à priori, en tout cas selon mon interprétation de la licence CC-By-SA sur les données. Je ne demande qu'a être contredit par un juriste, ce sera avec plaisir.
La notion de produit dérivé sur les données est tellement floue que la plupart des boites qui s'intéressent à OSM soit le pillent completement en douce, soit font demi tour devant les problèmes juridiques et techniques que cette notion induit.
Je trouve que le procès fait à Mappy relève plus d'une réaction épidermique contre l'arrivée des entreprises dans le monde de la donnée libre que d'une réelle analyse des tenants et des aboutissants. Ça ne donne pas une très bonne image de la communauté. Pourquoi ne pas plutot engager un dialogue qui amènera à de la collaboration ?
# Bravo
Posté par Vincent P (site web personnel) . En réponse au journal Les 12 ans du W-Fenec. Évalué à 2.
T'as les stats de visite sur les 12 ans ?
# Bravo !
Posté par Vincent P (site web personnel) . En réponse au journal Sozi : vers un système de présentation alternatif libre. Évalué à 1.
Enfin un logiciel qui ouvre de nouvelles perspectives donc !
La démo rame un petit peu, et on peut se dire que plus on complexifie l'animation plus ça risque de ralentir non ? Il serait possible d'envisager des exports vers d'autres formats ? Voire carrément générer des vidéos ?
Ou bien est ce qu'il y a des lecteurs SVG plus efficaces que firefox ?
Et dans le genre video/présentation animée, celle ci est au top :
http://video.google.com/videoplay?docid=-5115609628556940516(...)
Si on pouvait avoir un soft qui permet simplement de faire ce genre d'animations ce serait vraiment chouette. Bon ok, ça demande également du talent graphique, certes.
Merci en tout cas !