Pour completer l'information sur le CSW Client, les sources et la documentation du projet son sur la forge Adullact http://adullact.net/frs/?group_id=728
Il est à préciser que la démo d'OpenLayers offline utilise une technologie, WebSQL, disponible sur Safari mobile et Chrome Lite, n'est pas une norme approuvé par le W3C dans le cadre de HTML5.
Cette technologie n'a pas été validé apr le W3C car certains éditeurs si sont opposé. Le W3C traville actuellement sur la technologie IndexedDB pour le offline.
"D'ailleurs ils ont ete renvoye pour une autorisation non permise du reseau de Google non pas pour leurs actes de vandalisme, ce qui reste tres revelateurs."
Ce qui revient au même, car je ne pense pas qu'être intervenant OSM soit interdit par Google.
Même en France on vire des personnes pour bien moins que ça, je pense qu'il n'y a aucune raison de s'insurger sur ces pratiques. D'ailleurs il n'est pas clair qu'il y a licenciement :
« Les deux personnes ayant effectué ces changements étaient des contractuels travaillant à leur compte tout en étant sur le réseau de Google. Ces derniers ne travaillent plus sur des projets de Google ».
Il est clair que c'est le battage mediatique qui a decide des actes de Google surtout apres ce qui s'est passe avec Mocality. D'ailleurs ils ont ete renvoye pour une autorisation non permise du reseau de Google non pas pour leurs actes de vandalisme, ce qui reste tres revelateurs.
Ed Parsons a eus aussi des mots tres justes quand un contributeur lui a demande s'il contribuait encore a OSM sur Twitter: il a repondu que non de peur de se faire accuser de vandalisme.
D'un point de vue purement humain et au regard de l'acte c'est peut être un peu excessif.
Mais, les préjudices indirects pour Google sont importants. Il suffit de voir tout le battage médiatique que cela a occasionné. A mon avis la cause du renvoi est cette mauvaise publicité plutôt que les actes eux mêmes.
Renvoyer les deux employés sans préavis ni condamnation encourue est-ce vraiment agir de manière responsable ? Vu les "dégâts" occasionnés, un simple rappel à l'ordre aurait été sans doute plus judicieux. 20 modifications ! Mazette, tout ça pour ça ! Activité réseau non autorisée par Google, on dégage le salarié ! N'est-il pas plutôt là le scandale ?
Merci à tous les contributeurs pour ce blog très intéressant et particulièrement pour ces revues de presse hebdo.
C'est un gros boulot et il est aprécié à sa juste valeur.
Longue vie à GéoTribu !
Frederic (voisin d'Arnaud sur Sophia Antipolis :-))
C'est vrai qu'il n'est pas beaucoup utilisé cet outil.
Peut-être qu'il nécessiterait une petite mise à jour :)
Faut que j'y réfléchisse et trouve un peu de temps.
Je viens d'essayer avec GlobalMapper, et moins de trois secondes a suffit pour afficher les mêmes données. J'en conclus que le problème est plutôt dans QGis que vraiment dans une quelconque explication sur la complétude d'un SIG bureautique.
Par contre, cela dépend des données. J'ai essayé avec d'autres donnée un peu moins volumineuses, et le temps de traitement est bien plus rapide, plus rapide que la bibliothèque JS.
Il y a différentes explications qui peuvent être notées. La principale est je pense que la librairie JS ne s'occupe que du rendu carto. Or les applications SIG Bureautiques vont également charger les attributs. Cela pourrait expliquer le différentiel temporel.
J'y suis allé moi aussi de mon test de charge sur cette bibliothèque javascript : 20 secondes pour un joli shapefile de 16 Mo. J'ai testé sur QGIS, ça a donné 2min40sec ! Il faudrait essayer avec d'autres solutions SIG bureautiques. Mais je ne me souviens pas que GeoFla se soit affichée un jour sur ArcGIS aussi rapidement.
Personnellement, je pense qu'il y a un vrai problème de conception si une application en javascript est plus rapide qu'une application bureautique compilée. Je suis particulièrement heureux pour ces applications web, mais je ne vois pas la raison pour laquelle le SIG bureautique installé à demeure sur le PC doit être plus lent.
SI j'ai un seul truc à retenir c'est le support du format Edigeo dans la prochaine version de gdal. Permettant ainsi de s'affranchir de Topocad (uniquement sous windows, mais gratuit et fonctionnant très bien) afin de convertir ce format vectoriel vers un autre.
Bonjour,
Je suis archéologue et j'envisage de faire des recherches sur les nécropoles mérovingiennes, c'est-à-dire de croiser des données
tels que le nombre de sépultures, les objets en Île-de-France. Pour voir les récurrences j'ai donc besoin d'un SIG, je connaissais
déjà MAPINFO, mais je veux passer à un autre logiciel (gratuit !). OpenJump me paraît très bien, sauf que je ne sais si je peux
faire des requetes croisées du genre "nombre de sépultures plus grand que 100 et présence d'au moins 3 épées".....
Quelqu'un pourrait-il m'aider dans cette lourde tâche ? Merci d'avance...
Est ce que ce tuto est toujours d'actualité, je vois que certains liens ne sont plus à jour (le lien sur FeatureServer par exemple), je voudrais installer une mini application de ce type afin de modifier des ichiers Geojson en ligne.
Avez vous une autre idée d'un outil (le plus simple possible) qui peut faire ça ?
Merci pour la vidéo. De ton côté quelles sont tes impressions concernant cette version mobile.
Saurais-tu s'il est prévue une version plus adaptée aux devices tactiles ?
Bonjour,
J'ai résolu mon problème. En fait le keytool me donnait un clef en SHA1 et non MD5.
pour obtenir le MD5, il faut utiliser la commande keytool -v -list -keystore c:\Users\Vinss\.android\debug.keystore
Pour completer l'information sur le CSW Client, les sources et la documentation du projet son sur la forge Adullact http://adullact.net/frs/?group_id=728
Merci
Essayez cependant d'utiliser la version 3 de l'API ;)
Le tuto date un peu, mais n'empêche que j'ai quand même envie de dire merci ! :D
Il est à préciser que la démo d'OpenLayers offline utilise une technologie, WebSQL, disponible sur Safari mobile et Chrome Lite, n'est pas une norme approuvé par le W3C dans le cadre de HTML5.
Cette technologie n'a pas été validé apr le W3C car certains éditeurs si sont opposé. Le W3C traville actuellement sur la technologie IndexedDB pour le offline.
"D'ailleurs ils ont ete renvoye pour une autorisation non permise du reseau de Google non pas pour leurs actes de vandalisme, ce qui reste tres revelateurs."
Ce qui revient au même, car je ne pense pas qu'être intervenant OSM soit interdit par Google.
Même en France on vire des personnes pour bien moins que ça, je pense qu'il n'y a aucune raison de s'insurger sur ces pratiques. D'ailleurs il n'est pas clair qu'il y a licenciement :
« Les deux personnes ayant effectué ces changements étaient des contractuels travaillant à leur compte tout en étant sur le réseau de Google. Ces derniers ne travaillent plus sur des projets de Google ».
Il est clair que c'est le battage mediatique qui a decide des actes de Google surtout apres ce qui s'est passe avec Mocality. D'ailleurs ils ont ete renvoye pour une autorisation non permise du reseau de Google non pas pour leurs actes de vandalisme, ce qui reste tres revelateurs.
Ed Parsons a eus aussi des mots tres justes quand un contributeur lui a demande s'il contribuait encore a OSM sur Twitter: il a repondu que non de peur de se faire accuser de vandalisme.
D'un point de vue purement humain et au regard de l'acte c'est peut être un peu excessif.
Mais, les préjudices indirects pour Google sont importants. Il suffit de voir tout le battage médiatique que cela a occasionné. A mon avis la cause du renvoi est cette mauvaise publicité plutôt que les actes eux mêmes.
A.
Renvoyer les deux employés sans préavis ni condamnation encourue est-ce vraiment agir de manière responsable ? Vu les "dégâts" occasionnés, un simple rappel à l'ordre aurait été sans doute plus judicieux. 20 modifications ! Mazette, tout ça pour ça ! Activité réseau non autorisée par Google, on dégage le salarié ! N'est-il pas plutôt là le scandale ?
Guillaume
Bonjour Frederic,
Je te remercie pour ce commentaire. C'est agréable et encourageant.
A l’occasion, puisque nous sommes voisins, il faudra qu'on se rencontre ;)
A.
Merci à tous les contributeurs pour ce blog très intéressant et particulièrement pour ces revues de presse hebdo.
C'est un gros boulot et il est aprécié à sa juste valeur.
Longue vie à GéoTribu !
Frederic (voisin d'Arnaud sur Sophia Antipolis :-))
C'est vrai qu'il n'est pas beaucoup utilisé cet outil.
Peut-être qu'il nécessiterait une petite mise à jour :)
Faut que j'y réfléchisse et trouve un peu de temps.
Au passage, je ne comprends pas que l'auteur n'ait pas utilisé le fabuleux outil ImageMap BaseLayer :
http://geotribu.net/applications/baselayers/index.php :)
Merci Jérôme pour tes nombreuses interventions - toujours constructives.
A l'année prochaine pour de nouvelles revues de presse.
Je croyais que la question à poser serait plutôt OSM vs BD TOPO© ou OSM vs Navtech par exemple ? Un OSM en carte, ce n'est pas plutôt un FranceTopo.fr ?
Dans l'exemple de Cédric Moullet, http://tools.geofabrik.de/mc/?mt0=mapnik&mt1=googlemap&lon=14.71882&lat=... le gros pâté blanc est-il sensé représenter l'exhaustivité des données Google Maps ?
Et puis merci à toute l'équipe pour ces 52 revues de presse de l'année 2011 !
Vive les 52 prochaines :P
++
Jérôme
Bonjour,
Je viens d'essayer avec GlobalMapper, et moins de trois secondes a suffit pour afficher les mêmes données. J'en conclus que le problème est plutôt dans QGis que vraiment dans une quelconque explication sur la complétude d'un SIG bureautique.
Par contre, cela dépend des données. J'ai essayé avec d'autres donnée un peu moins volumineuses, et le temps de traitement est bien plus rapide, plus rapide que la bibliothèque JS.
Bonnes fêtes de fin d'année !
Jérôme
Bonjour,
Il y a différentes explications qui peuvent être notées. La principale est je pense que la librairie JS ne s'occupe que du rendu carto. Or les applications SIG Bureautiques vont également charger les attributs. Cela pourrait expliquer le différentiel temporel.
D'autres avis ?
Arnaud
J'y suis allé moi aussi de mon test de charge sur cette bibliothèque javascript : 20 secondes pour un joli shapefile de 16 Mo. J'ai testé sur QGIS, ça a donné 2min40sec ! Il faudrait essayer avec d'autres solutions SIG bureautiques. Mais je ne me souviens pas que GeoFla se soit affichée un jour sur ArcGIS aussi rapidement.
Personnellement, je pense qu'il y a un vrai problème de conception si une application en javascript est plus rapide qu'une application bureautique compilée. Je suis particulièrement heureux pour ces applications web, mais je ne vois pas la raison pour laquelle le SIG bureautique installé à demeure sur le PC doit être plus lent.
SI j'ai un seul truc à retenir c'est le support du format Edigeo dans la prochaine version de gdal. Permettant ainsi de s'affranchir de Topocad (uniquement sous windows, mais gratuit et fonctionnant très bien) afin de convertir ce format vectoriel vers un autre.
Bonjour,
Je suis archéologue et j'envisage de faire des recherches sur les nécropoles mérovingiennes, c'est-à-dire de croiser des données
tels que le nombre de sépultures, les objets en Île-de-France. Pour voir les récurrences j'ai donc besoin d'un SIG, je connaissais
déjà MAPINFO, mais je veux passer à un autre logiciel (gratuit !). OpenJump me paraît très bien, sauf que je ne sais si je peux
faire des requetes croisées du genre "nombre de sépultures plus grand que 100 et présence d'au moins 3 épées".....
Quelqu'un pourrait-il m'aider dans cette lourde tâche ? Merci d'avance...
Bonjour,
Effectivement le lien ne semble plus d'actualité.
Je vais essayer de me renseigner pour voir ce qu'il en est.
A.
Bonjour,
Est ce que ce tuto est toujours d'actualité, je vois que certains liens ne sont plus à jour (le lien sur FeatureServer par exemple), je voudrais installer une mini application de ce type afin de modifier des ichiers Geojson en ligne.
Avez vous une autre idée d'un outil (le plus simple possible) qui peut faire ça ?
Merci d'avance.
Salut Yves,
Merci pour la vidéo. De ton côté quelles sont tes impressions concernant cette version mobile.
Saurais-tu s'il est prévue une version plus adaptée aux devices tactiles ?
Arnaud
Bonjour,
Voici une vidéo réalisée par GeoBretagne et diffusé lors de la journée QGIS-fr du 26 octobre 2011 à Paris. Je viens juste de la mettre en ligne.
http://www.youtube.com/watch?v=j4-11wu58jY
Y.
Pour l'accidentologie routière, Data.gouv.fr a du lire votre article ;)
Bonjour,
J'ai résolu mon problème. En fait le keytool me donnait un clef en SHA1 et non MD5.
pour obtenir le MD5, il faut utiliser la commande keytool -v -list -keystore c:\Users\Vinss\.android\debug.keystore
Par contre, mon application ne se lance pas... :(