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.
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)
le développement y a l'air plus facile qu'avec gmapsAPI ! en 10 lignes de JS on a une carte !
