[EVOLUTION?] MySQL OpenGIS

Problème/bug rencontré sur le site, évolution/amélioration à proposer
Avatar du membre
yip
Messages : 204
Enregistré le : mar. 09 mars, 2004 12:32 am

[EVOLUTION?] MySQL OpenGIS

Message par yip » mar. 12 févr., 2013 7:01 am

Bon, ca s'adresse surtout à Sly et Dominique, les codeurs.

On passe à OpenGIS (Spatial DB) ?
Pour une meilleure gestion des données spatiales. On pourrai passer vers MySQL OpenGIS, il y a du boulot mais ca a l'air de se faire.

-Il n'y a pas tant d'interêt à passer à Postgre ou MySQL 5.6, la 5.0 permet déja de bosser.

-Le gain en terme de code est apparement énorme sur beaucoup de fonctions modèles, et sur nav.php.

-Gros gain aussi en MySQL, puisque il y aurait suppression de 2 tables obsolètes.

-Ca peut se faire petit à petit en remplacant fonction par fonction.


Pour l'instant:
-2 colonnes ont été rajoutées, une dans les points et une autre dans les polys. (Dommage que le Phpmyadmin soit trop vieux pour les comprendre)
-les points sont convertis et les nouveaux devraient l'être automatiquement (fonction d'ajout modifiée)
-les polygones sont convertis, ou remplacés par d'autres plus petits si démesurément grands. Contrairement aux points, ce n'est pas automatique.

Bref ça avance, et ça promet :P
je vais stocker des infos techniques dans le sous-rep GIS.

Avatar du membre
yip
Messages : 204
Enregistré le : mar. 09 mars, 2004 12:32 am

Message par yip » mar. 12 févr., 2013 7:37 am

dans PHPmyadmin
les champs GIS sont des éspèce de Blob binaires.

pour y voir plus clair:
SELECT AsText(gis) AS WKT FROM popoly WHERE nom_massif='vanoise' # ou du style ...

le résultat est donc un WKT... format de base d'OpenLayer, qui peut s'afficher avec un

Code : Tout sélectionner

pwkt = new OpenLayers.Format.WKT();
layerMassifs.addFeatures(  pwkt.read(   WKT    );  // ou a peu près 
... et fait gagner un fichier entier de code PHP 8)

Malheureusement, ca ne marche qu'avec la version OL2.12 officielle, pas avec la OL2.12.1.3 custom (OpenLayers.Format.WKT is not a constructor, alors que si).
En passant, OL c'est vachement classe ! :shock: le développement y a l'air plus facile qu'avec gmapsAPI ! en 10 lignes de JS on a une carte !
Il y a beaucoup de differences entre la official et la custom ? en travaillant bien, GMLSLD() peut ne plus être nécéssaire, ainsi que pas mal de construction XML maison ?

Avatar du membre
Dominique
Messages : 1150
Enregistré le : sam. 08 avr., 2006 9:58 pm
Localisation : Chaville 92
Contact :

Message par Dominique » mar. 12 févr., 2013 10:35 am

yip a écrit :Bon, ca s'adresse surtout à Sly et Dominique, les codeurs.

On passe à OpenGIS (Spatial DB) ?
Pour une meilleure gestion des données spatiales. On pourrai passer vers MySQL OpenGIS, il y a du boulot mais ca a l'air de se faire.
Je ne suis pas un grand spécialiste, mais les quelques pages de doc que j'ai lu m'ont alléché.
Je dirais GO. Si je peux participer, n'hésite pas (bien que j'ai peu de temps en ce moment)
yip a écrit :Malheureusement, ca ne marche qu'avec la version OL2.12 officielle, pas avec la OL2.12.1.3 custom (OpenLayers.Format.WKT is not a constructor, alors que si).
En passant, OL c'est vachement classe ! :shock: le développement y a l'air plus facile qu'avec gmapsAPI ! en 10 lignes de JS on a une carte !
Il y a beaucoup de differences entre la official et la custom ? en travaillant bien, GMLSLD() peut ne plus être nécéssaire, ainsi que pas mal de construction XML maison ?
J'ai optimisé la taille de la lib servie dans WRI en n'incluant pas toutes les classes.
ça se fait en commentant les lignes qui vont bien dans /ol12.1.3/lib/Openlayers.js
Donc je n'inclue pas OpenLayers.Format.WKT.js actuellement.
Tu peux l'ajouter en décommentant la ligne et régénérer la lib compressée en passant par le menu gestion -> Compression de la librairie OpenLayers de WRI

Avatar du membre
sly
Messages : 1945
Enregistré le : dim. 29 févr., 2004 6:59 pm
Localisation : Chambéry - Savoie
Contact :

Re: [EVOLUTION?] MySQL OpenGIS

Message par sly » mar. 12 févr., 2013 12:07 pm

yip a écrit : On passe à OpenGIS (Spatial DB) ?
Je suis, moi aussi, de plus en plus pour.

J'ai eu une illumination sous ma douche :
- j'ai remis dans ma tête toutes mes idées d'évolutions (qui ne sont pas toutes bonnes à prendre pour autant) des 2 dernières années :
* Gestion des réserves naturelles et détermination des points y appartenant
* Idem pour les communes française
* Calcul des temps de trajet allant de refuge en refuge, et routage
* Ajout des objets OSM comme les campings, les hôtels, les chambres d'hôtes, les lacs, les sommets, les points de ravitaillement. De manière général les points qui peuvent être intéressants aux randonneurs de wri, mais que nous n'avons pas (ou plus) forcément besoin d'intégrer nous même et de maintenir à jour.
* Tout ce qui concerne l'existant de l'appartenance d'un point à un polygone, cette histoire de point double se trouvant au même endroit physique (refuges gardés et partie hiver)
* Simplification de la saisie de ces polygones par une coopération plus grande avec OSM qui dispose déjà de 95% de ceux pré-cités, et simplification par l'occasion de toutes les petites bidouilles d'import/export gpx, du gestionnaire de polygone de dominique

Et à chaque fois, je m'aperçois qu'une base spatiale simplifierait grandement la réalisation de ces idées, et peut-être que, car nous manquons tous de temps, celles-ci y seraient déjà si ce n'avait pas été aussi dur à faire.

J'ai peut-être semblé trop frileux dans mon message sur http://www.refuges.info/forum/viewtopic ... c&start=45 avec mon : " bref, un beau projet d'avenir, mais il faut un plan sérieux pour y parvenir. "

Mais je ne suis pas/plus si frileux que ça, on a beaucoup à y gagner je pense, dominique semblait assis avec son crayons pour nous écouter, yip semble plus que over archi motivé pour faire le saut (à se demander s'il n'a pas déjà converti tout le code de refuges.info !)

Mais pouce, pause, please : réfléchissons. Tout coder en live sur refuges.info me semble prendre le risque de voir débarquer un paquet d'erreur et bug, la solution mysql gis 5.0 est-elle pertinente ?
Je constate que la fonction utilisée dans la requête de yip : PolygonFromText n'est déjà pas une fonction OpenGIS standard, car elle devrait s'appeler :
ST_PolygonFromText
Pensons à la pérénité, il existe un standard, si nous codons tout "mysqlo-mysql" la migration ultérieur risque à nouveau d'être laborieuse
Pour une meilleure gestion des données spatiales. On pourrai passer vers MySQL OpenGIS, il y a du boulot mais ca a l'air de se faire.

-Il n'y a pas tant d'interêt à passer à Postgre ou MySQL 5.6, la 5.0 permet déja de bosser.
MySQL est il vraiment compatible OpenGIS ? toutes les docs semblent dire que non.
Exemple :
http://dev.mysql.com/doc/refman/5.0/en/ ... jects.html
Tout ce qui commence par MBR* n'est pas conforme à la spécification OpenGIS (sinon, ils auraient donner aux fonctions le nom standard commençant par ST_*)

Pour plus d'info, voici la liste des fonctions supportées par PostGIS 1.5 :
http://postgis.net/docs/manual-1.5/ch08.html

Il ne faut pas se mettre dans la tête que c'est inéluctable d'utiliser MySQL. Oui, c'est vrai, là on a la 5.0, mais on peut libérer notre esprit, j'ai une proposition qui me semble apporter, en plus, d'autres avantages au détriment d'une conversion qui peut s'avérer délicate, je l'accorde :

wri est actuellement en mutualisé sur un serveur gplservice, pas de postgresql en vue avant longtemps. Mais j'ai des solutions depuis 1 an de serveurs virtuels où on a total liberté. Donc :
- accès ssh
- on peut installer postgresql/postgis et mysql en même temps le temps d'une migration
- on est plus libres sur l'évolution des softs, des extensions
- on peut reprendre une partie des outils OSM qui font du OSM->postgis (plus besoin de les coder chacun) *
- pour le test/dev : je peux rendre disponible la machine virtuelle de prod et chacun peut, chez lui, faire tous les tests de son choix (j'utilise virtualbox)
- maintenant qu'on est 3 développeurs, une solution sous contrôle de source va se faire sentir, on pourrait enfin passer à un mode de développement un peu plus structuré ou plutôt que tout coder en prod comme des cochons on passe par un dépot de source style github et chacun propose ses modifs (si elles sont grosses) que chacun peut répercuter sur sa VM locale et tester, avant de valider en production


* cette partie me semble très importante, 100% des outils openstreetmap utilisent postgresql, on économiserait à mon avis pas mal sur l'import/export des polygones et autres points annexes
* On pourrait aussi profiter d'autres type d'exports de wri -> openlayers (pour faire baver dominique : http://postgis.net/docs/manual-1.5/ST_AsGML.html ) ou de wri -> gps

Alors ? avant de se lancer tête baissée que pensez-vous d'une telle option

J'ai oublié de préciser une info, non des moindre, que je bosse avec postgresql/postgis depuis maintenant 4 ans sur des projets OSM et que mon niveau est passablement monté, permettant d'envisager des transmissions de savoir, des conseils et un peu d'expérience donc.
Sans compté une communauté OSM ouverte, pleine de compétences de ce type, là où les compétences sur mysql spatial me semble moindre

Avatar du membre
sly
Messages : 1945
Enregistré le : dim. 29 févr., 2004 6:59 pm
Localisation : Chambéry - Savoie
Contact :

Re: [EVOLUTION?] MySQL OpenGIS

Message par sly » mar. 12 févr., 2013 2:43 pm

yip a écrit : je vais stocker des infos techniques dans le sous-rep GIS.
Je viens de parcourir le dossier et les fichiers. Bonne nouvelle, quelle que soit la solution retenue (mysql ou postgresql) ces opérations de conversion de chez nous vers GIS seront de toute façon nécessaires, et les requêtes seront sans doute les mêmes ou très proches.

Toutefois, le travail réalisé sur tout ce qui n'est pas wri (c'est à dire tous les polygones sauf les massifs) pourrait peut-être être abordé différemment car je dispose de sources externes assez homogènes (osm of course) dont le passage vers GIS est déjà prévu pour, avec les outils existants et sans trop de gymnastique.

Tout en nous garantissant la légalité de le faire.


Je rentre un peu plus dans les détails :
// un POLYGON est ferme en standard OpenGIS.
// notre base contient un mix de fermés et ouverts.
Allons bon ? je croyais que c'était fini cette histoire, tu peux citer un exemple ? notre tables de polygone ne doit contenir plus que des polygones fermés pourtant. D'ailleurs, ils ne peuvent pas être ouverts de par la logique du code puisque il n'est pas requis que le 1er et le dernier soit identique (d'ailleurs, même pas recommandé !), car un segment est rajouté entre le 1er et le dernier de manière imposée lors du traitement, mais pas dans la base.

Sources diverses :
// Departements francais
//source :
http://melusine.eu.org/syracuse/jms/depfr/
warning : est-ce bien autorisé de les récupérer ?
Aux départements précédents ont été ajoutés, à partir de contours obtenus avec google maps
Ouille, aille, pas bon ça, le tracé sur googlemaps n'est pas autorisé par leurs conditions d'utilisations.

Idem pour les autres sources, méfiance méfiance.

De plus, la qualité n'est pas forcément au rendez-vous, un point à tôt fait de se tirer en italie alors qu'il est en france à cause d'une frontière imprécise.

Je vais encore radotter et donner l'impression d'un commercial de chez OSM : mais osm, c'est bon, mangez en !
http://export.openstreetmap.fr/contours-administratifs/

Et en plus, j'ai tous les outils pour faire ça sans se prendre le choux.

Retour à la table des négociations ? une réunion tchat en direct, ça vous tente ? une réunion dans un refuges de montagne ?

Avatar du membre
sly
Messages : 1945
Enregistré le : dim. 29 févr., 2004 6:59 pm
Localisation : Chambéry - Savoie
Contact :

Message par sly » mar. 12 févr., 2013 6:53 pm

Pour faire suite :

IRC, vous utiliseriez, genre ce soir pour en causer ?

Xchat pour windows :
http://www.silverex.info/download/

Pour osX :
http://xchataqua.sourceforge.net/twiki/ ... in/WebHome

Et bien sûr, pour linux, dans toutes les bonnes crémeries : toutes les distributions l'ont dans le package manager

et ça existe aussi en plugin firefox pour tous :
https://addons.mozilla.org/fr/firefox/addon/chatzilla/

Thème de la soirée (celle-ci ou une prochaine ou plusieures) :
== Base spatiale : validation de l'utilité pour wri ==
- comparaison, choix et avantage de mysql par rapport à postGIS (et inversement)
- si postgis, plan de bataille proposé par sly
- choix des provenances/sources de données spatiales de type polygones/points/ways
- cours dispensés par sly sur postGIS en 27 soirées simples, d'1h chacune

== gestion et organisation du développement ==
- Solutions à base de code publiée sur github (présentation par sly)
- Mise à disposition de VM pour le développement et les tests
- développement chacun chez soi pour éviter de tout casser, et publication des modifs, puis synchro avec la prod
- Se poser la question de savoir si sly ne va pas un peu loin avec tout ça

Avatar du membre
Dominique
Messages : 1150
Enregistré le : sam. 08 avr., 2006 9:58 pm
Localisation : Chaville 92
Contact :

Message par Dominique » mar. 12 févr., 2013 7:10 pm

sly a écrit :Pour faire suite :

IRC, vous utiliseriez, genre ce soir pour en causer ?
A quelle heure ?

Avatar du membre
sly
Messages : 1945
Enregistré le : dim. 29 févr., 2004 6:59 pm
Localisation : Chambéry - Savoie
Contact :

Message par sly » mar. 12 févr., 2013 7:44 pm

comme vous voulez, je suis dispo à partir de maintenant et jusqu'a tard

je suis d'ailleurs déjà sur irc :
serveur : irc.oftc.net
canal #wri

Il suffit décrire sly_ et je serais prévenu qu'il y a du monde

Avatar du membre
yip
Messages : 204
Enregistré le : mar. 09 mars, 2004 12:32 am

Message par yip » mar. 12 févr., 2013 7:52 pm

Dominique a écrit : Donc je n'inclue pas OpenLayers.Format.WKT.js actuellement.
Merci, je regarderais ça.
Aura-t'on vraiment besoin d'une version OL custom avec postGIS ?
sly a écrit : <...>car je dispose de sources externes assez homogènes (osm of course) dont le passage vers GIS est déjà prévu pour, avec les outils existants et sans trop de gymnastique.
100% pour, je savais bien que les polys administratifs venait de OSM, mais regarde plus bas.
sly a écrit : Allons bon ? je croyais que c'était fini cette histoire, tu peux citer un exemple ? notre tables de polygone ne doit contenir plus que des polygones fermés pourtant. D'ailleurs, ils ne peuvent pas être ouverts de par la logique du code puisque il n'est pas requis que le 1er et le dernier soit identique (d'ailleurs, même pas recommandé !), car un segment est rajouté entre le 1er et le dernier de manière imposée lors du traitement, mais pas dans la base.
Désolé, ils sont censés etre tous fermés maintenant. Dommage que l'ordre ne commence pas toujours à 0.
ma technique pour les reperer etait de compter les points_gps en doublons, s'il n'y en a pas, c'est ouvert.
Il y en avait 84.
Mais c'est pas fiable car certains autres faisaient des petites bouclettes internes, donc avec des petits doublons au milieu ...
Je ne pense pas qu'il y ait de poly avec Interior/Exterior ring, si ?
J'ai donc fermé les récalcitrants moitié à la main, moitié au SQL foireux.
De mémoire, l'Aragon et d'autres dans les pyrénées...
AFAIK, en OpenGIS, 1er = dernier pour POLYGON sinon c'est LINESTRING

sly a écrit : warning : est-ce bien autorisé de les récupérer ?
La source d'origine est un rectorat de l'education nationale (oui, ce qui ne veut rien dire)
sly a écrit : Idem pour les autres sources, mefiance mefiance.
Bien vu, c'est genant. J'ai evite ceux avec une licence explicite, meme en CC share-a-like.
Leur précision est très faible, plus faible que GEOFLA, plus faible qu'OSM ... ce qui rends la Donnée anonyme et sans valeur.
La grosse difficulté ça a été ça: trouver des sources a précision faibles.
+1 pour les refaire a partir d'autres sources (voir plus bas)
sly a écrit : De plus, la qualite n'est pas forcement au rendez-vous, un point a tot fait de se tirer en italie alors qu'il est en france a cause d'une frontiere imprecise.
C'etait voulu.
les pays a 30 000 points ça m'a fait mal aux yeux. genre la cote Bretonne super précise pour un polygone France.
De plus, c'est pas trop la peine de gagner sur la taille du JS si on balance des paramètres monstrueux à 100ko le poly.
les seuls dont la précision se justifiait à mes yeux sont les reserves et parcs, car ce sont les seuls qu'on zoome.
idem pour la précision à la 9e décimale: précision au millimètre près : rien que ça, ça double la taille du GML sans aucune utilité.

Effectivement, certains points frontaliers peuvent se retrouver à l'étranger.
Voila ce que je me suis dit:
Si tu cherches a faire une sortie en belledonne, ce n'est pas le dept francais du 38 qui te servira de carte, mais le massif. que la limite du dept passe exactement là où elle devrait ou à 300m au nord, c'est pas grave ?
Il faudrait un compromis en fait.
sly a écrit : Je vais encore radotter et donner l'impression d'un commercial de chez OSM : mais osm, c'est bon, mangez en !
http://export.openstreetmap.fr/contours-administratifs/
Carrément !
Juste faut voir les considération ci-dessus: nombre d'arretes et précision décimale.
Le top serait de choisir sa définition, mais AFAIK c'est pas possible: OSM fait toujours "au mieux", et grace a des gens comme Sly, ca veut dire "au top" ;).
Je reflechis a un algo de simplification de poly: chaud, chaud !

Comme tu le vois, je pense que cette histoire de complexité de polygones a une grande importance. J'y ai passé la moitié du WE, et c'est à cause de polys gigantesques que j'ai fait planter le serveur MySQL.
Sur le Net, certains disent qu'à 50 000 points, OL commence a ramer.
Sur les GIS standard online, genre carmen carto (Geo-IDE) dont le lien est dans le fichier, on le constate bien : c'est limite inutilisable. A moins d'avoir des PC de ouf. Le JS mouline comme un malade alors que la vue est super lointaine et la quantité d'infos visuelle est faible: paradoxe.
On le constate sur tous les GIS: dès qu'il y a du vectoriel, ça rame à fond, et c'est directement lié à la complexité des vecteurs.
Avec la multiplication des terminaux mobiles, qui sont moins puissants qu'un ordi, ça s'arrange pas.
C'est vachement dur de trouver des sources "low-definition" ! bien plus dur que de trouver des "HD" !

Avantage: comme les futurs poly sont sur un seul champs de la table polygones, c'est plus facile a refaire à partir d'une source externe que de l'existant, et je suis tout prêt à le refaire.

Et bien sur a tout laisser tomber pour
.
.
.

Bon maintenant le VRAI sujet levé par Sly
POSTGRES

C'est vrai que le MySQL/GIS est limité à ses petites fonctiounettes, gestions des WKT (direct Openlayers sans GML), des BBox, distances et fonctions MBR à la one-again, pas de SRID :pas du vrai OpenGIS, meme en 5.6. Comme MySQL qui n'est pas un vrai SGBD non plus et s'est imposé sur un malentendu ;) .
La conversion du site peut se faire petit à petit toute seule sans trop de boulot. comme elle a commencé. Malgré son manque d'ambition, ca simplifierait de beaucoup le code avec peu de travail.

PostGres, enfin un vrai SGBD, avec cerise sur le gateau un vrai support OpenGIS, en plus avec Sly en expert DBA, Allons-y !
Va y avoir du Taf !


(va pour IRC)

Avatar du membre
sly
Messages : 1945
Enregistré le : dim. 29 févr., 2004 6:59 pm
Localisation : Chambéry - Savoie
Contact :

Message par sly » mar. 12 févr., 2013 8:00 pm

Je viens de lire rapidos tes inquiétudes, et je peux répondre à chacune d'entre elle coté serveur (avec postgis of course) mais je suis moins à l'aise avec openlayers.

Mais ça peut devenir brouillon par forum, ce que je ferais si pas d'irc, mais ça pourrait être plus simple et "moins de latence" si nous sommes là tous les 3.

J'expliquerais alors comment ça se gère super bien coté serveur de multiple façon, et dominique pourra nous dire : oulla, ou pas, ou si et même ouba

Je suis sur irc

Avatar du membre
Dominique
Messages : 1150
Enregistré le : sam. 08 avr., 2006 9:58 pm
Localisation : Chaville 92
Contact :

Message par Dominique » mar. 12 févr., 2013 8:40 pm

yip a écrit :
Dominique a écrit : Donc je n'inclue pas OpenLayers.Format.WKT.js actuellement.
Merci, je regarderais ça.
Aura-t'on vraiment besoin d'une version OL custom avec postGIS ?
Voilà. J'ai inclu le format WKT (quelques Ko de + dans la lib ne nuira pas)

Avatar du membre
sly
Messages : 1945
Enregistré le : dim. 29 févr., 2004 6:59 pm
Localisation : Chambéry - Savoie
Contact :

Message par sly » mar. 12 févr., 2013 8:43 pm

Le format WKT étant plus concis, on pourrait imaginer gagner du temps coté openlayers, mais en terme d'envoi, tout est compressé gzip, donc ça ne devrait pas changer des masses.

A voir à l'usage, gml ayant quand même l'avantage de faire passer + d'infos

sinon, si tu es un peu dispo dominique, on est tout les deux sur irc

Répondre

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 2 invités