Discussion :

[dgrichard]

Bon ok gardons ces 3 classes mais le sens de mon message était "rendez les simple a utiliser". Masquez la problématique des projections!!

Pourquoi, c'est l'essence même de la Géomatique. D'ailleurs, c'est ce que font les APIs standard et étendue.

Je dirais plus que c'est une surcouche d'OpenLayers + un gros Hack d'OpenLayers(il suffit de regarder la classe js OverloadedOpenLayersMinimum.js) qui est présente dans l'API Minimale

Cette classe c'est 4000 lignes de code, de fonction Openlayers redéfinies...

Dont combien sont des lignes de commentaires/documentations ? bien plus de 50% ...

C'est pas ce que j'appelle une surcouche "propre"

Merci pour le propre. Si tu trouve comment maintenir une surcouche OpenLayers en gérant ces évolutions et celles d'OpenLayers sans toucher au code original d'OpenLayers, je prends

Sinon, il est préférable d'être plus constructif dans les appréciations données.

Au passage, bon nombre des lignes de codes des surcharges auraient pu être insérées dans le projet OpenLayers comme contributions, mais la CCLA OenLayers est juridiquement inapplicable pour une administration française... et cela fait deux ans que l'on en discute au sein de l'OSGéO.
Il fallait donc trouver un système simple de surcharges JS, non instrusif dans le code OpenLayers.

[geomuse]

Bon désolé pour le ton du précédent post, c'est pas très constructif je le reconnait.
mais c'est que je suis frustré de pas pouvoir avoir un fond de plan Geoportail et en même temps un OpenLayers "standard".

Au final je crois que je vais laisser tomber.

Pourquoi, c'est l'essence même de la Géomatique. D'ailleurs, c'est ce que font les APIs standard et étendue.

La je suis pas d'accord, on fait de la geomatique mais on fait surtout du web. L'api google y arrive, rendre simple des choses compliqués, c'est possible

Merci pour le propre. Si tu trouve comment maintenir une surcouche OpenLayers en gérant ces évolutions et celles d'OpenLayers sans toucher au code original d'OpenLayers, je prends



Sinon, il est préférable d'être plus constructif dans les appréciations données.

il est possible de créer des sous classes aussi. il faut penser aussi que l'API OpenLayers peut être utilisée par d'autres bout de script de la page et que si on modifie son comportement initial, ca met en vrac cette partie la.

Bon ok techniquement il y avait peut être pas d'autres solutions, ca je veux bien l'entendre mais je trouve que c'est quand même une "vampirisation" d'openlayers et tant pis pour ceux qui ont besoin d'avoir la version "originale"
Dommage tout de même pour une version "minimale"

Au passage, bon nombre des lignes de codes des surcharges auraient pu être insérées dans le projet OpenLayers comme contributions, mais la CCLA OenLayers est juridiquement inapplicable pour une administration française... et cela fait deux ans que l'on en discute au sein de l'OSGéO.
Il fallait donc trouver un système simple de surcharges JS, non instrusif dans le code OpenLayers.

La c'est sur que d'intégrer le projet OpenLayers ca aurait été le mieux. Je vois pas très bien ce que ca change au niveau des Conditions/licences/etc entre une participation au projet initiale ou une utilisation + une surcharge par contre mais bon.

[dgrichard]

La c'est sur que d'intégrer le projet OpenLayers ca aurait été le mieux. Je vois pas très bien ce que ca change au niveau des Conditions/licences/etc entre une participation au projet initiale ou une utilisation + une surcharge par contre mais bon.

Bon nombre de surcharges seraient passées dans le code OpenLayers tout simplement

[geomuse]

Bon nombre de surcharges seraient passées dans le code OpenLayers tout simplement

ca c'est technique, tu me parlais du juridique ;-)

[dgrichard]

ca c'est technique, tu me parlais du juridique ;-)

Et moi, je sous-entendais les deux

1/ Juriquement, le texte est impossible à appliquer à une administration;

2/ Le code de l'API est ouvert ... à tout contributeur OpenLayers qui peut indiquer sa source pour le bien (bénéfice) de la communauté;

3/ Les surcharges ne contiennent plus que ce qui n'est pas utile à la communauté

[geomuse]

Et moi, je sous-entendais les deux

1/ Juriquement, le texte est impossible à appliquer à une administration;

Oui c'est la que je comprends pas, vous n'êtes pas sensé déjà appliquer le texte puisque vous utilisez OpenLayers. Pour moi il n'y a aucune différence en "utiliser" ou "contribuer puis utiliser". En plus l'effort de contribution peut être fait au nom d'un individu (drichard par exemple ) et non de l'IGN. M'enfin, je veux bien comprends que l'administration c'est compliqué...

2/ Le code de l'API est ouvert ... à tout contributeur OpenLayers qui peut indiquer sa source pour le bien (bénéfice) de la communauté;

3/ Les surcharges ne contiennent plus que ce qui n'est pas utile à la communauté

oups je comprends pas ces phrases(trop de négations non dans la 2ieme??)

Sinon ce que je voulais signaler, c'est que les entreprises qui utilisent OpenLayers de manière industrielle sur des projets ne peuvent pas se permettre d'avoir une version modifiée par l'API Geoportail. Comment savoir ensuite si la nouvelle version d'OpenLayer corrige tel ou tel bug? Comment savoir s'il ne va pas y avoir des effets de bord sur la surcharge de l'API Geoportail?
Pour moi c'est ingérable sauf si on se dit "On utilise OpenLayers 2.9 et ca bougera plus".

[dgrichard]

Oui c'est la que je comprends pas, vous n'êtes pas sensé déjà appliquer le texte puisque vous utilisez OpenLayers. Pour moi il n'y a aucune différence en "utiliser" ou "contribuer puis utiliser". En plus l'effort de contribution peut être fait au nom d'un individu (drichard par exemple ) et non de l'IGN. M'enfin, je veux bien comprends que l'administration c'est compliqué...

C'est par méconnaissance de ta part du dossier :

1/ utiliser OpenLayers : c'est avant tout le dire (en-tête licence);

2/ modifier OpenLayers pour corriger des bugs est nature (les différentes versions d'OpenLayers le font et rajoutent des fonctionnalités à l'instar de l'API Géoportail Javascript);

3/ Porter ces modifications dans OpenLayers nécessite de signer la ICLA (pour les individus) et la CCLA pour les "entreprises".

Jusqu'à maintenant, l'individu dgrichard est contributeur de projet Open Source sur son temps libre. Il a donc signé les ICLA de ces projets en son nom.
OpenLayers en tant que brique fondatrice de l'API Géoportail et du fait que le dit individu passe sur son temps de travail à l'utiliser/modifier/amender, il est inconcevable qu'il signe la ICLA (d'autant plus qu'il n'est pas seul à faire ce travail).
C'est donc important pour un établissement public de pouvoir contribuer ... si la CCLA le permet. Et justement, l'IGN en tant que sponsor associé à l'OSGéO a pu entamer par le biai de contributeurs français à OpenLayers à faire ce travail de négociation.

Sinon ce que je voulais signaler, c'est que les entreprises qui utilisent OpenLayers de manière industrielle sur des projets ne peuvent pas se permettre d'avoir une version modifiée par l'API Geoportail. Comment savoir ensuite si la nouvelle version d'OpenLayer corrige tel ou tel bug? Comment savoir s'il ne va pas y avoir des effets de bord sur la surcharge de l'API Geoportail?
Pour moi c'est ingérable sauf si on se dit "On utilise OpenLayers 2.9 et ca bougera plus".

Le raisonnement ne tient pas : nous avons débuté l'API avec OpenLayers 2.5 en avril 2008 et notre développement d'aujourd'hui utilise OpenLayers 2.10. Pourquoi ? parce que cette bibliothèque évolue en ajoutant/corrigeant des fonctionnalités de première importance pour nos utilisateurs (support Canvas, nouveaux contrôleurs, services OGC, etc ...). Notre travail consiste à amortir les changements OpenLayers dans l'API :

1/ L'API 1.0 repose sur OpenLayers 2.8;
2/ L'API 1.1 repose sur OpenLayers 2.9.1;
3/ L'API 1.2 reposera sur OpenLayers 2.10.

A chaque fois, il suffit de lire les CHANGELOG d'OpenLayers, puis les CHANGELOG de l'API.

Les utilisateurs ont bénéficié à chaque fois des avancées sans rien modifier dans leur page (sauf au passage 1.0bêta vers 1.x).

Pour les effets de bord, je les laisse à ton appréciation puisque tu y tiens : nous avons incorporer l'API dans des sites utilisant OpenLayers sans aucun retour de la part des utilisateurs (sauf bug dans notre API). De plus, le nombre de surcharges de l'API a été petit à petit incorporer à OpenLayers.

Mais, le pire (pour nous) sera à venir avec OpenLayers 3.0 ...

[geomuse]

C'est par méconnaissance de ta part du dossier :

1/ utiliser OpenLayers : c'est avant tout le dire (en-tête licence);

2/ modifier OpenLayers pour corriger des bugs est nature (les différentes versions d'OpenLayers le font et rajoutent des fonctionnalités à l'instar de l'API Géoportail Javascript);

3/ Porter ces modifications dans OpenLayers nécessite de signer la ICLA (pour les individus) et la CCLA pour les "entreprises".

Jusqu'à maintenant, l'individu dgrichard est contributeur de projet Open Source sur son temps libre. Il a donc signé les ICLA de ces projets en son nom.
OpenLayers en tant que brique fondatrice de l'API Géoportail et du fait que le dit individu passe sur son temps de travail à l'utiliser/modifier/amender, il est inconcevable qu'il signe la ICLA (d'autant plus qu'il n'est pas seul à faire ce travail).
C'est donc important pour un établissement public de pouvoir contribuer ... si la CCLA le permet. Et justement, l'IGN en tant que sponsor associé à l'OSGéO a pu entamer par le biai de contributeurs français à OpenLayers à faire ce travail de négociation.



Le raisonnement ne tient pas : nous avons débuté l'API avec OpenLayers 2.5 en avril 2008 et notre développement d'aujourd'hui utilise OpenLayers 2.10. Pourquoi ? parce que cette bibliothèque évolue en ajoutant/corrigeant des fonctionnalités de première importance pour nos utilisateurs (support Canvas, nouveaux contrôleurs, services OGC, etc ...). Notre travail consiste à amortir les changements OpenLayers dans l'API :

1/ L'API 1.0 repose sur OpenLayers 2.8;
2/ L'API 1.1 repose sur OpenLayers 2.9.1;
3/ L'API 1.2 reposera sur OpenLayers 2.10.

A chaque fois, il suffit de lire les CHANGELOG d'OpenLayers, puis les CHANGELOG de l'API.

Les utilisateurs ont bénéficié à chaque fois des avancées sans rien modifier dans leur page (sauf au passage 1.0bêta vers 1.x).

Pour les effets de bord, je les laisse à ton appréciation puisque tu y tiens : nous avons incorporer l'API dans des sites utilisant OpenLayers sans aucun retour de la part des utilisateurs (sauf bug dans notre API). De plus, le nombre de surcharges de l'API a été petit à petit incorporer à OpenLayers.

Mais, le pire (pour nous) sera à venir avec OpenLayers 3.0 ...

Ok pour la licence, dommage que ce soit si compliqué de participer à un projet OpenSource.

Pour le reste, je reste sur le constat qu'il y a ce qu'on appelle un couplage fort en informatique entre OL et l'API et que, par conséquent, ça complique l'intégration. Tel que tu le décris, si aujourd'hui j'ai un client qui souhaite passer à OpenLayers 2.10 parce que certains bugs important y sont corrigés, je dois dire "Désolé il faut attendre la sortie de l'API Geoportail 1.2"

[dgrichard]

Ok pour la licence, dommage que ce soit si compliqué de participer à un projet OpenSource.

Ne mélange pas tout : je n'ai jamais eu ces problèmes avec d'autres projets Open source où je suis contributeur ...

Pour le reste, je reste sur le constat qu'il y a ce qu'on appelle un couplage fort en informatique entre OL et l'API et que, par conséquent, ça complique l'intégration.

Oui, c'est un choix que de travailler avec OpenLayers, je l'assume. C'est le propre de l'open source : avoir le choix.

Une porte de sortie serait Mapstraction

Tel que tu le décris, si aujourd'hui j'ai un client qui souhaite passer à OpenLayers 2.10 parce que certains bugs important y sont corrigés, je dois dire "Désolé il faut attendre la sortie de l'API Geoportail 1.2"

Amusant comme approche, as-tu la même attitude vis-à-vis d'autres composants logiciels qui utilisent des sous-composants boggués dont tu sais que les versions ultérieures les corrigent (en général, je me prends par la main : récupère les sources et recompile le tout).

Rien n'empêche de faire le portage par toi-même et de nous en faire profiter (ça aussi, c'est l'Open source: le partage, mais pas à sens unique).

J'ai eu aussi le cas d'un partenaire en 2.6 pour qui nous avons modifié l'API minimum pour qu'il passe en 2.10. Cela nous a servi de base aux travaux actuels de passage en 2.10 pour le reste de l'API. Le coût fut très élevé : 1/2 journée de travail

[geomuse]

Tu as de la chance d'avoir le choix des technos que tu utilises.
J'espère en tout cas que ces choix seront bons parce qu'à l'autre bout de la chaine il y a ceux qui ne l'ont plus, le choix.
De plus en plus dans les administrations, on va imposer aux prestataires l'intégration des couches geoportail dans les sites cartos. Donc bien obligé d'utiliser les technos choisies par l'IGN

Donc faites les bons choix et surtout, laissez nous de la marge de manœuvre

[bestgirl88]

slt svp qui peut m'aider comment faire pour ajouter un nouveau API à visual c++ si vous savez bien les (étapes précises) et merci cordialement

[shama]

Donc faites les bons choix et surtout, laissez nous de la marge de manœuvre

On peux difficilement faire plus ouvert que ce qui existe. L'accès aux sources + doc de bonne qualité... Moi je redis bravo, car le développeur ne peux être coincé

[geomuse]

bon si je suis le seul a galérer avec l'API minimale mea culpa

Enfin shama, tu m'as l'air d'être bien plus expérimenté qu'un développeur lambda

S'il y a d'autres personnes qui utilisent l'API minimale, manifestez vous!

D'accord avec toi pour dire c'est cool d'avoir les sources, après la doc et les exemples je reste un peu sur ma faim.
Genre l'exemple Mapfish qui marche que sur 5 niveau de zoom...C'est cool mais dès qu'on veut tous les niveaux de zoom la ca se complique...Ça fait un peu l'exemple marketing, on montre le petit bout qui marche

[cmail]

Pour te rassurer, tu n'es pas le seul à galérer! Mais moi, c'est par incompétence qu'un travail assidu a du mal à combler...
Et si tu en appelles à des manifestations, fais gaffe car bestgirl88 nous en fait voir de toutes les couleurs...
A ce propos, je lui conseille d'ouvrir un nouveau fil de discussion, avec sa question mûrement et posément réfléchie...

[dgrichard]

slt svp qui peut m'aider comment faire pour ajouter un nouveau API à visual c++ si vous savez bien les (étapes précises) et merci cordialement

il est inutile d'hurler ... sur le net personne n'écoute

Sinon, voir là

[dgrichard]

S'il y a d'autres personnes qui utilisent l'API minimale, manifestez vous!

Beaucoup de sites le font pourtant :

crue 1910
fiches géodésiques

et d'autres comme l'ordre des géométres experts, le ministère de la culture (mais qui nécessite un compte).

D'accord avec toi pour dire c'est cool d'avoir les sources, après la doc et les exemples je reste un peu sur ma faim.
Genre l'exemple Mapfish qui marche que sur 5 niveau de zoom...C'est cool mais dès qu'on veut tous les niveaux de zoom la ca se complique...Ça fait un peu l'exemple marketing, on montre le petit bout qui marche

De nouveau, tu n'étudies pas le code patiemment. Les 5 niveaux de zoom sont liés à la carte en projection Mondiale.
Pour faire plus, il faut reprendre certaines partie du code de l'API pour avoir simplement les autres (sans ceux-là) ou tous les niveaux avec des projections différentes (le hook est juste sur la méthode OpenLayers.Map.setBaseLayer() avec l'émission de l'évènement "changebaselayer" ... Tout cela n'est pas dans l'API minimum car beaucoup de classes OpenLayers sont touchées dans la gestion de changement de baseLayer à projection non compatible.

Bref: aide-toi et le ciel t'aidera

[geomuse]

Heu excuse moi mais ces 2 sites n'utilisent pas l'API minimale mais un truc appelé API_Extended....

Et le site sur les crues c'est magique mais on ne peux pas voir la France en entier, probablement a cause de ce problème de cohabitation entre les 10-15 niveaux de zoom les plus résolus et les 5 niveaux les moins résolus...

[cmail]

Et le site sur les crues c'est magique mais on ne peux pas voir la France en entier,

Heu? (Sous controle de dgrichard) Je crois que c'est bien voulu: 7 niveau de zoom et centré sur le nord de la France comme semble le montrer le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// On recentre
		if(zoom>13){
			showM.map.getMap().setCenter(center, 13);
		}
		if(zoom<6){
			showM.map.getMap().setCenter(center, 6);
		}
				
		// Determination de l'emprise de la carte
		var mapBounds = new OpenLayers.Bounds();
		mapBounds = showM.map.getMap().getExtent();
		mapBounds.transform( showM.map.getMap().getProjection(), showM.map.getMap().displayProjection);
		var swlon = mapBounds.left.toFixed(6);
		var nelon = mapBounds.right.toFixed(6);
		var nelat = mapBounds.top.toFixed(6);
		var swlat = mapBounds.bottom.toFixed(6);
		var nivzoom = showM.map.getMap().getZoom();

Non?


Par contre, il me semble bien qu'à l'est de Gueret se trouve un POI qui ouvre une photo de Alfortville?????? A confirmer et à corriger

[dgrichard]

Heu excuse moi mais ces 2 sites n'utilisent pas l'API minimale mais un truc appelé API_Extended....

Toutes mes excuses, un copier/couiller malencontreux

En voici un (ouvrir le + sur la droite de la carte pour changer de carte --par défaut Google--)

Et le site sur les crues c'est magique mais on ne peux pas voir la France en entier, probablement a cause de ce problème de cohabitation entre les 10-15 niveaux de zoom les plus résolus et les 5 niveaux les moins résolus...

C'est l'éditorial du site : « Crues du bassin de la Seine »

Pour avoir l'ensemble des zooms, il faut mettre en oeuvre l'écoute de l'évènement "changebaselayer". C'est plus compliqué et c'est dans l'API standard / étendue uniquement.