| 1 | |
| Auteur | Messages |
|---|---|
| manu | #1 Posté le 18/6/2010 à 21:10:00 |
Avec Gambas ca roule ! | Bonjour, Voila, comme certains le savent peut être, je suis paysan, comme notre amis Gambix soit dit au passage, mais je suis loin d'avoir son niveau en informatique et en Gambas. J'en suis au stade ou je commence a comprendre les rudiments de Gambas alors que Gambix écris des composants et participe a l'écriture de Gambas. Mais, l'autre point commun, c'est que je rêve de développer des applications pour nous les pecnos et sous nux bien sure. Bon je commence gentiment avec des petits outils que je ne diffuse pas qui sont plutôt des prétextes a mon apprentissage de Gambas. Tous ca pour m'excuser par avance, que je ne comprends pas toujours tous... Bref Les application SIG ont toute leur place dans notre profession, pour noter graphiquement tous un tas de données telles que les cultures dans nos parcelles, les apports d'engrais, de fumier etc, les traitement, les modes d'exploitions, les rendements et j'en passe. Ce type d'application existe déja sur la Daube Gagnante (Win Daube) en soft proprio et très cher en plus ! Nous devons tous les ans déclarer nos surfaces mis en culture sur un site (telepac) qui est du SIG pur et dur. Un applet java permet de dessiner les parcelles sur une vue aerienne, les couper, les regrouper etc et d'y saisir des données comme la cultures, si c'est en bio etc... Personnellement je trouve l'application génial et donc ca donne des envies d'autant que les données que l'on peu saisir ne sont que les données qui intéresse une certaine administration. Le site permet de générer des fichier shape pour l'instant inutilisable dans gambas. Ok pourquoi je raconte tous ca ? Je me suis dit que je pourrais exploiter ces fichiers afin de saisir l'ensemble des données qui m'intéresse moi et qui intéresse aussi d'autres administrations. La première idée consistait à convertir ces fichier shape en fichier KML qui est le format Google map/earth.puis afficher ces données dans un webView. et la, les problèmes commencent. Bon la conversion a l'air de fonctionner correctement mais impossible de faire afficher mes polygones correctement dans google earth et impossible de les faire s'afficher sur une googleMap. pour Google map j'ai pas du tous comprendre. Voir discution sur ForumSIG.org (moi c'est manu56) 2 ieme probleme : quand j'arriverais a afficher mes polygone ds une google map, comment vais je faire interagir entre ce qui est dans mon webview et le reste de mon application. En fait, je me demande si c'est la bonne orientation que je prends. avez vous des idées ,d'ordre générale je veux dire, pour aborder cette problématique ? Jeanne d'arc, elle a frit, elle a tout compris !  Config : Manjaro linux (excellent !) XFCE 4.1 (simple et efficace) Gambas 3 dans les dépots (confort total) |
| Pablodetaix | #2 Posté le 19/6/2010 à 08:48:00 |
| bonjour Manu, il est fort probable que le site dont tu parles soit "client" de la société ESRI qui utilise le format SHAPE. de mémoire, je dis bien de mémoire, ce "format" est multiple, il contient à la fois les infos géo référencées et une description littérale des objets. Je crois que ce format est documenté, il est devenu sans abus de langage, un "standard de fait" par son utilisation. il doit je crois avoir 3 fichiers un shx shp et dbf (historique) tu devrais aller jetter un oeil sur QGIS / OPENJUMP / GVSIG je crois pas avoir ce format sous la main Quand au prix des SIGWin ... tu as raison, cher... et souvent "pseudo captif" vu du coté client... trés liés en plus à la version de l'OS et meme souvent pire liés étroitement au moteur graphique sur lesquels la plupart s'appuient... en effet peu de societé du domaine ce sont lancées dans le dév d'un moteur graphique propriétaire (trop risqué, trop cher en dév, pas assez rapide en réactivité par rapport au marché pour dire à un client potentiel "j'ai la soluce elle tourne..." donc on trouve bcp de soft dit "SIG" qui ne font que "masquer" un moteur de type AUTOCAD/ MICROSTATION etc... en outre un sig qui n'est pas nativement topologique est lent à l'execution car pour "masquer" ces lacunes on cré des routines/macro appelles ça comme tu veux qui "font semblant" ça ajoute une couche de traitement fondamentalement inutile et qui ajoute une instabilité par rapport aux écarts d'évolution entre l'OS, le moteur graphique, et la partie "SIG" collé dessus. Combien de SIG sont né de la vente d'un noyau AUTOCAD, de qq macros en langage script Autocad... et roule ma poule ! ce qui fait licence WIN, licence Moteur, licence BAse de donnée, et Une Louche pour "le développeur du SIG" chacun prenant sa part en "maintenance et maj" le tout souvent transitant par la société "au front" qui vendait son SIG=> elle prenait sa marge sur chaque élément... juteux.. et beaucoup ont profité de la méconnaissance de ces principes auprès de clients émus de voir de la couleur à l'écran et des cartes sur lesquelles ont pouvait zoomer et cliquer ! mais je crois bien que le format shape est documenté et que l'import ne doit pas poser de gros problèmes... qq soit le format il faut se pencher sur la structure de l'information de base. je veux dire inutile de s'embeter a charger la déinition des symboles, des types de traits etc... dans un premier temps. la description géo-référencée n'est que la mise en paralléle de deux "informations" la description de l'objet géométrique ponctuel lineaire surfacique, un identifiant... (souvent même 2 ou 3... d'autant plus que le fichier a pour origine un moteur graphique "ancien" non topologique et/ou non conçu pour la géographie) un des identifiants "graphique" sert a faire le lien avec une description des attributs de l'objet (sa ou ses fiches dans une base le plus souvent externe à l'appli SIG) PArfois tu peux avoir une troisième série d'information "le décalage de coordonnées" ou plus exactement "le systeme de projection utilisé" pour plusieurs raisons 1) certains moteurs graphiques n'aiment pas les coordonnées Lambert carto.... en encore moins les coordonnées sphériques de projection latitude / longitude...2) pour améliorer les temps de réponses d'une couche SIG ajoutée sur un outil DAO, on peut lors de l'import faire un changement de systeme de coordonnées une fois pour toute et obtenir un systeme plus adapté aux traitements que l'on veut faire, dans ce cas, selon le niveau de l'import ou de l'export on perd ou pas en précision.... Par contre perso je ne me suis jamais penché sur les formats utilisés par Google map etc... Voilà si ça peut faire avancer le schmilblick ! Pablo. | |
| manu | #3 Posté le 21/6/2010 à 07:17:00 |
| Avec Gambas ca roule ! | Merci pour cette longue réponse. Bon, après en avoir parler avec Gambix, je vais me concentrer dans un premier temps sur la partie non SIG de mon application et puis nous ferons ensemble après la partie Carto. On aura surement besoins de tes lumières à ce moment là :). Mais juste pour info, comment on gère les "calques" sur la carte dans Gambas ? J'entends par calques, les ojets graphiques que l'on superpose sur la carte. On utilise une DrawArea ou l'on dessine la carte puis les diffèrents objets ? Peux tu m'expliquer le principe général ? Jeanne d'arc, elle a frit, elle a tout compris ! Config : Manjaro linux (excellent !) XFCE 4.1 (simple et efficace) Gambas 3 dans les dépots (confort total) |
| Pablodetaix | #4 Posté le 21/6/2010 à 09:37:00 |
| Pour les calques... 1ere notion hormis les aspects de l'affichage Les systèmes de DAO/CAO gérent des "niveaux" ou "calques" ou "couches" (layers sous Autocad par exemple, sous microstation historiquement c'était que des N° pour identifier les couches, puis il sont passés aux noms eux aussi) Chaque niveau ainsi déclaré, contient la description des objets que l'on y a mis. cela sert à structurer/organiser les données et faciliter quelques commandes... ex couche "Cadastre" contient les limites de parcelles,les limites des constructions etc... couche "monprojet" les objets qui t'interessent et qui ne sont pas décris ailleurs, par exemple "la tiers nord de la parcelle AD-32 ds la commune petaoushnock qui a subit tel traitement "agricole" Des "boutons/menus etc" permettent de voir ou pas tel niveau/couche dans son ensemble (ex Ne plus voir le cadastre) Si le système identifie en lui-meme les objets par un code objet,un identifiant unique, une description géométrique et une description littérale, alors on est pas obligé de séparer en couche... c'est plus logique de mettre les maisons, avec les maisons, mais pas obligatoire... A l'inverse si le système ne sais pas identifier que le trait 22,noir, de 2/10mm est un élément de contour de la maison 33, alors là on sera obliger de faire "plein" de couches pour "séparer" les objets.... c'est pour cela qu'il y a une grande différence entre la notion de couche au sens SIG/GIS et au sens "moteur de Dessin" surtout si le moteur de dessin n'est pas topologique....(car justement il perd, ou n'a meme jamais eu ces liens de corrélations/appartenance d'un vecteur par rapport a l'objet qu'il represente) si tu dessines en noir sur une feuille de papier une parcelle rectangulaire, en bord de parcelle dans un angle, en noir aussi, une maison.. tu montres ton dessin a quelqu'un d'autre... comment peut il deviner que le petit rectangle est une maison dans le grand rectangle qui est la parcelle ?.... surtout que ça peut etre l'inverse: Une GRANDE maison construite sur 2 parcelles.... Si tu met des couleurs et une légende.... n'importe qui peut comprendre la structure du dessin.... tu transposes cela en structure de données Dossier/niveau/objet dans le niveau... et tu as une approche (simpliste) de la construction d'objet dans un SIG. c'est pas compliqué. peut être nouveau pour toi, mais pas compliqué. Un SIG sait reconnaitre que pour 2 traits d'apect et de coordonnées identiques, l'un est un "bord maison" du niveau cadastre, l'autre par exe une partie de limite de zone inondable... Quand a l'affichage ... là c'est une autre notion. ton systeme dessine (comme les objets d'un form après tout ....) tout ce qu'il doit montrer. certains objets sont relativement figés... (par ex les limites de parcelles, mis à jour tous les x mois ou années....) et d'autres vont bouger plus vite... en découpant ton affichage en N listes d'affichage... tu peux optimiser les temps de traitements.... ne pas régénérer l'intégralité du dessin. Tu ajoutes le fait qu'il vaut mieux afficher "en dernier" les objets qui t'interessent le + pour "mieux les voir" si tu dessines des puits, et des parcelles "opaques". si tu dessines dans la mémoire video les puits avant les parcelles...ben tu verras pas les puits.... mais un SIG est capable de "pointer/trouver" un objet, non pas parcequ'il est visible à l'écran, mais parcequ'il est dans la mémoire des objets qui sont "près" de ce point(x,y,z) ou alors pour voir les puits, tu dessines les parcelles "transparentes" ou les puits aprés les parcelles... Maintenant avec des drawarea, opengl, cairo (que je connais pas en pratique) cela est géré par les lib. d'appel. d'ou en général la richesse des fonctions et le nbre de paramètres qui existent pour elles. Autre approche : Qd tu fais un "timer" ou un "socket" dans un form GB => il est bien là ! il a un (x,y) connu par GB ds le form, mais tu ne le vois pas à l'execution et il est bien là ! il est donc bien dans la liste d'objet du Form,de la classe TRUC, avec ses attributs... La structuration en couche permet d'appliquer des règles de visu rapide (cacher tout un niveau, le voir en couleur, le voir en niveau de gris, etc...) et d'eviter de mélanger tout et n'importe quoi.... en plus c'est un élément clef lors de l'import de données... 3 niveaux = Cadastre/Ton projet/image raster satellite ou autre lors de la mise a jour du cadastre tu "Ré-importe" que les données "que l'extérieur" t'a fourni à jour... en l'occurence les services du cadastre. ça te fixe un peu les idées ? Pablo | |
| manu | #5 Posté le 21/6/2010 à 12:51:00 |
| Avec Gambas ca roule ! | oui trés bien Pablo, surtout que j'ai déjà essayer des logiciel SIG a vocation agricole donc je vois tres bien ce que tu veux dire. En tous cas merci pour toutes ces précisions  C'est sure, vaut mieux que Gambix prenne en mains cette partie SIG :o)Jeanne d'arc, elle a frit, elle a tout compris ! Config : Manjaro linux (excellent !) XFCE 4.1 (simple et efficace) Gambas 3 dans les dépots (confort total) |
| gambix | #6 Posté le 21/6/2010 à 18:32:00 |
Faire simple ! | et c'est fout ce que ça ressemble a gb.report sauf que moi je gère en plus les objet a dessiner en fonction de leur caractère visible ou non c'est a dire si lors d'un zoom;certaine partie de la page est masquée alor les objets caché ne sont pas déssiné... on gagne en rapidité de dessin. gb.report est très spéciae a cause du traitement pour l'arrangement ... 5 mois a m'arracher les cheveux mais ... je dois en refaire une partie car il ne fait pas tout comme je veut ... ce n'est pas un système par section mais par contrainte ... comme pour les formulaires de gambas. et des règle qui permettent de chasser ou non un élément de la page a la page suivante si certaines option sont ou non cochée. On passe un tableau de collection ou un result a reportvbox et hop miracle les label se remplissent en fonction des keys donnée. enfin vous verrez cela une fois fini. Moins de texte dans une signature c'est agrandir son espace. |
| Pablodetaix | #7 Posté le 21/6/2010 à 20:04:00 |
| ça a l'air de valoir le détour.... je vais devenir curieux... Bonne soirée, Pablo | |
| 1 | |