Discussion :

[courdi95]

Dans le fichier MapWinGIS.wl, je ne trouve aucune trace des classes "Utils" ou "Image" .... et dans l'outil WDXView pour l'activeX MapControl de MapWinGIS, je ne vois pas ces classes non plus .....

Je suis sans doute à côté de la plaque ... tu peux me recadrer SVP ?

[OnePoint]

Dans le fichier MapWinGIS.wl, je ne trouve aucune trace des classes "Utils" ou "Image" .... et dans l'outil WDXView pour l'activeX MapControl de MapWinGIS, je ne vois pas ces classes non plus .....

Je suis sans doute à côté de la plaque ... tu peux me recadrer SVP ?

Pour aller au plus vite, est-ce que tu as un logiciel MS Office dont tu pourrais utiliser l'EDI VBA: Excel, Word, ... ?
C'est bien pratique d'utiliser l'explorateur d'objets sur le fichier ocx...

[courdi95]

J'ai visual studio exprèss. C'est suffisant ?

[OnePoint]

Désolé, je dois m'arrêter pour ce soir.

J'ai visual studio exprèss. C'est suffisant ?

Sûrement, il faut ajouter le fichier mapwingis.ocx dans le Projet et ouvrir l'Explorateur d'objets pour regarder la bibliothèqe MapWinGIS.


En attendant, tape ces 2 mots-clés dans ton moteur de recherche:
utils ReprojectShapefile

Et tu auras des résultats qui pointent dans la doc de MapWinGIS et sûrement plein d'autres trésors que je ne connais pas encore.

Bonne soirée.

[courdi95]

Bon, les objects Automation ce n'est pas mon truc ....

1. MapWinGis version OCX

J'ai essayé de récupérer les dimensions de la carte affichée en utilisant un objet Extents .... sans succès :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
nom_fichier est une chaîne = "c:\Temp\world_adm0.shp"
SfWorld est un objet  Automation "MapWinGIS.Shapefile"
 
SfWorld>>Resource(nom_fichier)
AX_map>>AddLayer(SfWorld,-1)
 
autMapExtents est un objet Automation "MapWinGIS.Extents"
autMapExtents = AX_map>>Extents()
 
Trace (autMapExtents>>get_Xmax())

2. MapWinGis version .NET

Bon, maintenant concernant la version .NET de MapWinGis, suite à mes dernières mésaventures, PCSOFT m'a fourni un correctif qui permet de récupérer un objet COM et de le manipuler comme un objet .NET. Ce correctif sera sans doute intégré à la prochaine release de la V18 (remarque : je ne l'ai pas encore testé).

3. Composant Carto WD pur
Bon, comme je tournais en rond sur ce sujet, j'ai commencé le développement d'un composant de cartographie pur Windev (on revient donc dans le fil du sujet de ce post ).

Ce composant permet :

• l'affichage de dalles dans une fenêtre interne (qui peut être utilisée dans une fenêtre d'un projet avec votre propre interface)
• la taille de la fenêtre est redimensionnable avec retracé automatique
• les dalles peuvent être mises en cache dans une base HF locale
• les dalles sont obtenues à partir du serveur de tuile OpenMapQuest
• la projection est donc du Mercator EPSG 3857
• le composant permet l'ajout/la suppression de POIs
• la souris permet de déplacer par glissement
• on peut zoomer la carte (tous les zooms permis par le serveur de dalle)
• on peut augmenter ou diminuer la résolution d'affichage des dalles
• on peut cliquer sur les points d'intérêts
• on peut sélectionner une zone (box) et avoir les informations de positions correspondantes
• on peut positionner un marqueur en cliquant sur la carte

Je déposerai le composant dès qu'il sera plus avancé sur le serveur de dépot de PCSOFT.

PS : des pouces +1 sur ce post m'encourageraient bien (et ferait grimper mon compteur !)

[OnePoint]

Bonjour,

1. MapWinGis version OCX

J'ai essayé de récupérer les dimensions de la carte affichée en utilisant un objet Extents .... sans succès :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
nom_fichier est une chaîne = "c:\Temp\world_adm0.shp"
SfWorld est un objet  Automation "MapWinGIS.Shapefile"
 
SfWorld>>Resource(nom_fichier)
AX_map>>AddLayer(SfWorld,-1)
 
autMapExtents est un objet Automation "MapWinGIS.Extents"
autMapExtents = AX_map>>Extents()
 
Trace (autMapExtents>>get_Xmax())

Dans ce qui suit, je parle d'utiliser le composant et la bibliothèque ActiveX MapWinGIS (pas de .NET).

Quand un contrôle / composant ActiveX renvoie un objet automation, en fait il renvoie une "référence" sur cet objet.
Dans l'application Windev, il faut affecter cette référence à un objet Automation dynamique.

Code :

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

1
2
3
4
autMapExtents est un objet Automation dynamique  // "MapWinGIS.Extents"
autMapExtents = AX_map>>Extents
 
Trace (autMapExtents>>xMax())

En passant, tu t'emmêles entre la bibliothèque .NET et la bibliothèque ActiveX.
• avec l'ActiveX: utiliser simplement la propriété xMax d'un objet Automation MapWinGIS.Extents
• avec .NET: utiliser la méthode get_xMax (pour .NET, les méthodes get_* et set_* donnent accès aux propriétés des objets)

Alors pour aller jusqu'au bout...

Dans un "MapWinGIS.Shapefile", voilà comment sélectionner les "MapWinGIS.Shapes" qui sont totalement ou partiellement dans une zone délimitée par un "MapWinGIS.Extents".

axMap est le champ ActiveX qui contient le contrôle "MapWinGIS.Map".

la constante SelectMode_INTERSECTION est définie dans le fichier MapWinGIS.wl joint dans un message plus haut dans la discussion

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
18
19
20
21
22
23
24
25
26
27
 
oExtents est un objet Automation dynamique	// "MapWinGIS.Extents"
 
// agrandir au maximum la zone d'affichage du contrôle
// pour visualiser tous les "objets" des différents "layers"
axMap>>ZoomToMaxExtents
 
// référencer un objet "MapWinGIS.Extents" qui décrit la zone d'affichage du contrôle Map
oExtents = axMap>>Extents
 
oSF est un objet Automation dynamique	// "MapWinGIS.Shapefile"
oPoint est un objet Automation dynamique	// "MapWinGIS.Point"
bSuccess est un booléen
tShapeIndex est un tableau de entiers
nShapeIndex est un entier
 
// référencer l'objet "MapWinGIS.Shapefile" correspondant au premier "Layer"
oSF = axMap>>GetObject(0)
bSuccess = oSF>>SelectShapes(oExtents, 0, SelectMode_INTERSECTION, tShapeIndex)
 
Trace(bSuccess,tShapeIndex..Occurrence)
 
// parcourir tous les Shapes sélectionnés et afficher les coordonnées du premier point
POUR TOUT nShapeIndex DE tShapeIndex
	oPoint = oSF>>QuickPoint(nShapeIndex,0)
	Trace("Point: ",oPoint>>x,oPoint>>y)
FIN

[OnePoint]

3. Composant Carto WD pur
Bon, comme je tournais en rond sur ce sujet, j'ai commencé le développement d'un composant de cartographie pur Windev (on revient donc dans le fil du sujet de ce post ).

Bon courage.

SI je peux me permettre une suggestion...

Commencer par traiter tous les points qui concernent les dalles:
comment récupérer le fichier, comment est spécifiée l'échelle (nb de pixels par mètres ???), comment les informations de projection sont-elles codées avec l'image...

• les dalles peuvent être mises en cache dans une base HF locale
• les dalles sont obtenues à partir du serveur de tuile OpenMapQuest
• la projection est donc du Mercator EPSG 3857
• on peut zoomer la carte (tous les zooms permis par le serveur de dalle)
• on peut augmenter ou diminuer la résolution d'affichage des dalles

Ce serait sympa de nous tenir au courant...

[courdi95]

Merci à OnePoint pour sa contribution dans l'utilisation de la version OCX pure de MapWinGis .... Je ferai l'essai.

Visiblement, l'utilisation de la version Ocx pose moins de souci que la version .Net pour laquelle PCSOFT a du faire des correctifs .... Attendre donc la prochaine release de la V18 pour en profiter.

Pour mon composant pur WD, et pour essayer de répondre aux questions de OnePoint :

• "comment récupérer le fichier" : je ne comprends pas la question ... de quel fichier parles-tu ?
• "comment est spécifiée l'échelle (nb de pixels par mètres ???)" : l'échelle n'apparait pas pour le moment dans mon composant (voir plus loin sur l'utilisation des dalles type Google)
• "comment les informations de projection sont-elles codées avec l'image..." : je ne comprends pas la question ... la projection utilisée par Google est du Mercartor (alias SRID 3857) .... j'utilise directement les dalles que je colle dans une image, sans reprojection ni rien ... donc ma carte (qui est donc un patchwork) utilise la même projection que les dalles qui sont utilisées pour faire le pavage.

Pour tout ce qui concerne la projection utilisée et la manière dont on peut manipuler les dalles, lire la page web suivante :
http://www.maptiler.org/google-maps-...ds-projection/

Pour les dalles MapQuest que je charge, je les obtiens avec la version Open :
http://developer.mapquest.com/web/products/open/map

[OnePoint]

Pour mon composant pur WD, et pour essayer de répondre aux questions de OnePoint :

• "comment récupérer le fichier" : je ne comprends pas la question ... de quel fichier parles-tu ?
• "comment est spécifiée l'échelle (nb de pixels par mètres ???)" : l'échelle n'apparait pas pour le moment dans mon composant (voir plus loin sur l'utilisation des dalles type Google)
• "comment les informations de projection sont-elles codées avec l'image..." : je ne comprends pas la question ... la projection utilisée par Google est du Mercartor (alias SRID 3857) .... j'utilise directement les dalles que je colle dans une image, sans reprojection ni rien ... donc ma carte (qui est donc un patchwork) utilise la même projection que les dalles qui sont utilisées pour faire le pavage.

Pour tout ce qui concerne la projection utilisée et la manière dont on peut manipuler les dalles, lire la page web suivante :
http://www.maptiler.org/google-maps-...ds-projection/

Pour les dalles MapQuest que je charge, je les obtiens avec la version Open :
http://developer.mapquest.com/web/products/open/map

Désolé si je suis confus, je ne connais pas grand chose à tout ça...

Dans un SIG, qu'appelle-t-on "dalle" (ou "tuile") ?

Si je comprends bien... une "dalle" est une image rectangulaire (donc un fichier image) qui représente une fraction de la surface du globe terrestre, projetée dans un plan (surface plane) qui possède un système de coordonnées.

Qui dit "dalle", dit aussi:
• fichier image,
• système de projection utilisé,
• coordonnées de l'image dans ce système (centrées ?, bounding-box ?)
• expression des coordonnées (latitude/longitude, coordonnées dans le système de projection...)
• échelle / résolution (par exemple, 1 pixel = n mètres)

Certains formats de fichiers regroupent tout ça, comme par exemple GeoTIFF (une extension du format TIFF).

Dans le cas d'un format de fichier dépourvu d'informations géographiques, il est possible d'associer au fichier image, un fichier complémentaire ("fichier world") qui contient certaines de ces informations géographiques.

Avec MapQuest, il est probable que tu récupères une image "simple", sans information géographique.

Récupérer plusieurs dalles et les assembler dans un affichage, comme une mosaïque, ne me semble pas facile.

Supposons que tu veuilles récupérer les dalles nécessaires à l'affichage de la France, comment faut-il s'y prendre ?
(il faudra sans doute récupérer n fichiers en précisant les coordonnées...)

En fait, je ne te demande pas une réponse, mais voilà, c'est juste que ça m'intrigue...

Aussi je comprends l'intérêt d'un contrôle comme MapWinGIS.Map, mais hélas on manque de documentation.
Si je comprends bien, le contrôle MapWinGIS.Map peut charger des images de dalles (avec les infos de projection) dans différents "layers" et les afficher "correctement".
En passant, il y a deux propriétés du contrôle "MapWinGIS.Map" qui ont sans doute un rapport avec ça :
• CurrentScale (pas beaucoup d'explications )
• MapUnits (prévue pour: mm, cm, m km, pouces, pieds, yards, miles, degrés décimaux)


Autre chose... Si tu gères toi-même l'affichage de POIs dont les coordonnées sont des latitudes/longitudes, alors il faudra coder le calcul de la projection dans le système de coordonnées utilisé pour les dalles (ou utiliser une bibliothèque, ou un outil en ligne de commande).
Tu as déjà prévu quelque chose ?

Attention, je suis dans l'hypothèse d'une application off-line, ce qui était le sujet initial de la discussion.

Quoiqu'il en soit, je t'envoie plein d'ondes positives pour t'encourager !

[courdi95]

Désolé si je suis confus, je ne connais pas grand chose à tout ça...

Dans un SIG, qu'appelle-t-on "dalle" (ou "tuile") ?

Si je comprends bien... une "dalle" est une image rectangulaire (donc un fichier image) qui représente une fraction de la surface du globe terrestre, projetée dans un plan (surface plane) qui possède un système de coordonnées.

Effectivement si tu regardes le lien que j'ai indiqué sur les tuiles "A la Google", les serveurs de tuiles (comme OpenMapQuest) proposent de fournir des images de 256x256 pixels, avec un système d'adressage simple (tx, ty , zoom : voir le lien ... ). "tx" : numéro en abscisse de la tuile et "ty" : numéro en ordonnées de la tuile.

Qui dit "dalle", dit aussi:
• fichier image,
• système de projection utilisé,
• coordonnées de l'image dans ce système (centrées ?, bounding-box ?)
• expression des coordonnées (latitude/longitude, coordonnées dans le système de projection...)
• échelle / résolution (par exemple, 1 pixel = n mètres)

Ce sont donc effectivement des images, et le principe est d'avoir des fonctions (je les ai programmées depuis fort longtemps en WD) qui permettent de passer d'une position lat/lon à px/py/zoom (px : position du pixel dans la grande image correspondant au zoom).

Comme cette grande image est ensuite décomposée en plusieurs tuiles de 256 pixels, on peut facilement calculer le numéro de la tuile dans laquelle se trouve l'image :
tx = PartieEntiere(px/256)
et la position du pixel dans cette tuile = px - PartieEntiere(px/256)*256.

Certains formats de fichiers regroupent tout ça, comme par exemple GeoTIFF (une extension du format TIFF).

Exact, l'avantage des tuiles, c'est que tu ne consommes que ce dont tu as besoin, et que la tuile est de fait géoréférencée (tu peux facilement calculer le lat/lon du pixel en haut à gauche connaissant la valeur tx/ty/zoom de la tuile). Donc pas besoin de fichier de projection, car c'est implicite ...

Dans le cas d'un format de fichier dépourvu d'informations géographiques, il est possible d'associer au fichier image, un fichier complémentaire ("fichier world") qui contient certaines de ces informations géographiques.

Même remarque que précédemment, les coordonnées tx/ty/zoom de la tuile te donnent sa position.

Avec MapQuest, il est probable que tu récupères une image "simple", sans information géographique.

Récupérer plusieurs dalles et les assembler dans un affichage, comme une mosaïque, ne me semble pas facile.

C'est assez simple en fait ....

J'ai programmé deux possibilités :
- une base HF de type atlas intégrant pas mal de tuiles, avec une connexion internet en option pour la nourrir
- une connexion internet pour récupérer les tuiles en dynamique, avec une base HF locale pour faire un cache et éviter de perdre du temps

Ces bases me permettent de créer une image patchwork avec les différentes dalles ... (dCopieImage....)... Il faut ensuite gérer proprement les déplacements de souris pour déplacer la carte.

Supposons que tu veuilles récupérer les dalles nécessaires à l'affichage de la France, comment faut-il s'y prendre ?
(il faudra sans doute récupérer n fichiers en précisant les coordonnées...)

Des requêtes vers Mapquest httpRequete avec comme paramètres tx,ty et zoom des dalles que je veux récupérer.

En fait, je ne te demande pas une réponse, mais voilà, c'est juste que ça m'intrigue...

Aussi je comprends l'intérêt d'un contrôle comme MapWinGIS.Map, mais hélas on manque de documentation.
Si je comprends bien, le contrôle MapWinGIS.Map peut charger des images de dalles (avec les infos de projection) dans différents "layers" et les afficher "correctement".

L'avantage de MapWinGis est de pouvoir ingérer des shapefiles ....

En passant, il y a deux propriétés du contrôle "MapWinGIS.Map" qui ont sans doute un rapport avec ça :
• CurrentScale (pas beaucoup d'explications )
• MapUnits (prévue pour: mm, cm, m km, pouces, pieds, yards, miles, degrés décimaux)


Autre chose... Si tu gères toi-même l'affichage de POIs dont les coordonnées sont des latitudes/longitudes, alors il faudra coder le calcul de la projection dans le système de coordonnées utilisé pour les dalles (ou utiliser une bibliothèque, ou un outil en ligne de commande).
Tu as déjà prévu quelque chose ?

J'ai traduit depuis fort longtemps les routines de conversion proposées dans le site web sur les dalles Google.

Attention, je suis dans l'hypothèse d'une application off-line, ce qui était le sujet initial de la discussion.

Quoiqu'il en soit, je t'envoie plein d'ondes positives pour t'encourager !

Moi aussi, la base locale HF permet de fonctionner off line. Dès qu'une connexion internet est dispo on peut l'enrichir.

[OnePoint]

Je me suis bien régalé à te lire.

Effectivement si tu regardes le lien que j'ai indiqué sur les tuiles "A la Google", les serveurs de tuiles (comme OpenMapQuest) proposent de fournir des images de 256x256 pixels, avec un système d'adressage simple (tx, ty , zoom : voir le lien ... ). "tx" : numéro en abscisse de la tuile et "ty" : numéro en ordonnées de la tuile.

[...]

Ce sont donc effectivement des images, et le principe est d'avoir des fonctions (je les ai programmées depuis fort longtemps en WD) qui permettent de passer d'une position lat/lon à px/py/zoom (px : position du pixel dans la grande image correspondant au zoom).

Comme cette grande image est ensuite décomposée en plusieurs tuiles de 256 pixels, on peut facilement calculer le numéro de la tuile dans laquelle se trouve l'image :
tx = PartieEntiere(px/256)
et la position du pixel dans cette tuile = px - PartieEntiere(px/256)*256.

[...]

Exact, l'avantage des tuiles, c'est que tu ne consommes que ce dont tu as besoin, et que la tuile est de fait géoréférencée (tu peux facilement calculer le lat/lon du pixel en haut à gauche connaissant la valeur tx/ty/zoom de la tuile). Donc pas besoin de fichier de projection, car c'est implicite ...

Même remarque que précédemment, les coordonnées tx/ty/zoom de la tuile te donnent sa position.

C'est assez simple en fait ....

Si ça continue, je vais finir par tout comprendre.

Pour arriver aux "256 px", il me manque encore une articulation essentielle qui tourne autour de la notion d'échelle.. mais toi tu parles de zoom.

Je reprends le principe...
Tu pars d'une projection géographique. A cette projection correspond une carte globale de la terre toute entière.

Projection cartographique
http://fr.wikipedia.org/wiki/Projection_cartographique

Cette carte globale peut être découpée en plusieurs dalles. Une dalle est un fichier graphique de n pixels de large par m pixels de haut, où n et m peuvent être 256.

Maintenant j'ajoute la notion d'échelle: la carte globale peut être représentée à différentes échelles.
Intuitivement, je ramène ça à la notion de résolution dans une image, c'est à dire que, plus la résolution est grande, plus il y a de pixels, pour une même surface.
J'imagine que plus l'échelle est grande, plus la carte globale comporte de pixels.
Autrement dit, il y a autant de cartes globales que d'échelles visualisables.

Ce qui veut dire que le calcul consiste à passer:
(1) des coordonnées latitude/longitude, vers les coordonnées dans la projection,
(2) des coordonnées dans la projection selon une échelle, vers les coordonnées en pixels.

A partir des coordonnées en pixel, tu peux déterminer quelle dalle à cette échelle contient le pixel.

Dans tes calculs, tu dois bien prendre en compte l'échelle, non ?

[courdi95]

Je me suis bien régalé à te lire.

Si ça continue, je vais finir par tout comprendre.

Pour arriver aux "256 px", il me manque encore une articulation essentielle qui tourne autour de la notion d'échelle.. mais toi tu parles de zoom.

Exact ... plus le zoom est grand, plus petite est l'échelle ...

Je reprends le principe...
Tu pars d'une projection géographique. A cette projection correspond une carte globale de la terre toute entière.

Projection cartographique
http://fr.wikipedia.org/wiki/Projection_cartographique

Cette carte globale peut être découpée en plusieurs dalles. Une dalle est un fichier graphique de n pixels de large par m pixels de haut, où n et m peuvent être 256.

Dans mon cas le découpage de la carte se fait en dalles de 256 pixels de côté.

Maintenant j'ajoute la notion d'échelle: la carte globale peut être représentée à différentes échelles.
Intuitivement, je ramène ça à la notion de résolution dans une image, c'est à dire que, plus la résolution est grande, plus il y a de pixels, pour une même surface.

Exact ... plus le zoom est grand, plus la carte finale correspondant à tout le globe est grande, et plus elle contient de pixels. Donc comme elle est plus grande, j'ai de plus en plus de dalles (qui elles font toujours 256x256 pixels).

J'imagine que plus l'échelle est grande, plus la carte globale comporte de pixels.
Autrement dit, il y a autant de cartes globales que d'échelles visualisables.

Exact ... c'est le niveau de zoom qui gère tout cela.

Ce qui veut dire que le calcul consiste à passer:
(1) des coordonnées latitude/longitude, vers les coordonnées dans la projection,

lat/lon -> on choisit un zoom -> px, py dans la "grande" carte

(2) des coordonnées dans la projection selon une échelle, vers les coordonnées en pixels.

exact, effectivement on passe par des "metres" à un moment donné dans le calcul avant d'arriver au px, py.... regarde bien le code python de la page web (sinon je t'enverrai mes routines).

A partir des coordonnées en pixel, tu peux déterminer quelle dalle à cette échelle contient le pixel.

oui c'est le plus simple.

Dans tes calculs, tu dois bien prendre en compte l'échelle, non ?

Je ne prends pas en compte l'échelle, mais le zoom.

[courdi95]

Les fonctions "magiques".

Pour passer de lat/lon à zoom/px/py, utiliser
LatLonToMeters
puis
MetersToPixels

ATTENTION !!! En fait il y a un "petit" bug .... il faut rentrer -lat comme valeur ....

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
PROCEDURE LatLonToMeters( lat, lon,mx,my )
 
//LatLonToMeters(self, lat, lon ):
//Converts given lat/lon in WGS84 Datum to XY in Spherical Mercator EPSG:900913"
 
mx = lon * OriginShift / 180.0
//grValPi est un réel = 3.14159265358979323
my = Ln( Tangente_radian((90 + lat) * grValPi / 360.0 )) / (grValPi / 180.0)
 
my = my * OriginShift / 180.0

Code :

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

1
2
3
4
5
6
7
8
9
PROCEDURE MetersToPixels(mx,my,zoom,px,py)
 
//def MetersToPixels(self, mx, my, zoom):
//"Converts EPSG:900913 to pyramid pixel coordinates in given zoom level"
res est un réel
 
res = Resolution( zoom )
px = (mx + OriginShift) / res
py = (my + OriginShift) / res

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
FONCTION Resolution(zoom)
 
//def Resolution(self, zoom ):
//"Resolution (meters/pixel) for given zoom level (measured at Equator)"
 
res est un réel
 
//# RETURN (2 * math.pi * 6378137) / (self.tileSize * 2**zoom)
//resolution = InitialResolution / (2**zoom)
 
res = InitialResolution / Puissance(2,zoom)
 
RENVOYER res

Les constantes !!

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
 
// constantes pour calcul Tile
//Initialize the TMS Global Mercator pyramid"
tileSize est un entier = 256
// ValPi = 3,14159265358979323
grValPi est un réel = 0n3.14159265358979323
InitialResolution est un réel = 2 * grValPi * 6378137 / tileSize
// 156543.03392804062 for tileSize 256 pixels
OriginShift est un réel = 2 * grValPi * 6378137 / 2.0
// 20037508.342789244
///////////////////////////////////////////////////
// rayon de la terre
grRayon_terre est un réel
grRayon_terre = 6378137 
///////////////////////////////////////////////////

Et pour revenir dans l'autre sens ....

Code :

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

1
2
3
4
5
6
7
8
 
PROCEDURE PixelsToMetersCE (px,py,zoom,mx,my)
 
res est un réel
res = Resolution( zoom )
 
mx = px * res - OriginShift
my = py * res - OriginShift

Code :

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

1
2
3
4
5
6
7
 
PROCEDURE MetersToLatLonCE(mx,my,lat,lon)
 
lon = (mx / OriginShift) * 180.0
 
lat = (my / OriginShift) * 180.0
lat = 2 * ArcTang( Exp(lat*grValPi/180.0)) - 180 / 2.0

ATTENTION !!! En fait il y a un "petit" bug .... on récupère -lat comme valeur .... il suffit de le savoir ...

[OnePoint]

C'est moi qui fait un blocage ou bien la notion de zoom n'est jamais abordée dans la littérature sur les SIG...

J'ai bien compris la relation entre les échelle et zoom, du point de vue de l'affichage.

exact, effectivement on passe par des "metres" à un moment donné dans le calcul avant d'arriver au px, py.... regarde bien le code python de la page web (sinon je t'enverrai mes routines).

Je suis très intéressé par le code WLangage correspondant au code python.

D'ailleurs, toute la page est bien intéressante.
http://www.maptiler.org/google-maps-...ds-projection/

Pour faire fonctionner ces tuiles avec MapWinGIS, je pense qu'il faut récupérer la tuile + ses coordonnées projetées.
Et la démo de la page web présente justement le calcul de ces coordonnées.


Merci d'avoir pris le temps de répondre.

[courdi95]

Pour le code windev, regarde mon post précédent. Nos réponses se sont croisées.

Quant a l'utilisation de mapwingis pour afficher des dalles c'est sans doute faisable au même titre qu'on peut afficher des images avec un fichier de projection. J'avoue que je n'aurai pas le temps de le regarder. Je préfère travailler sur la mise au point de mon composant full windev pour le moment.

Quand il sera au point, je regarderai comment y injecter des shapefile, mais j'ai des craintes sur les performances de rapidité de tracé de windev. .....

[courdi95]

Bing Maps utilise le même style de projection que MapQuest ou Google, mais un adressage différent :
http://msdn.microsoft.com/en-us/library/bb259689.aspx

Visiblement, on n'a pas besoin de clé pour accéder aux tuiles... (à vérifier)

[frenchsting]

Je n'y comprends pas grand chose mais je plussoie pour le boulot accompli.

PS : Lorsqu'un projet WD sera opérationnel, je veux bien essayer

[OnePoint]

Bonjour à tous !

Bing Maps utilise le même style de projection que MapQuest ou Google, mais un adressage différent :
http://msdn.microsoft.com/en-us/library/bb259689.aspx

Très très bien ce lien !

En plus, j'y trouve des informations complémentaires qui répondent à mes questions "philosophiques" sur zoom et échelle.
cf. la section "Ground Resolution and Map Scale" (dans cette page, on emploie l'expression "niveau de détail" au lieu du terme "zoom")

Et aussi la page supplémentaire "Understanding Scale and Resolution" (où cette fois c'est le terme zoom qui est utilisé ).
http://msdn.microsoft.com/en-us/library/bb259689.aspx

Visiblement, on n'a pas besoin de clé pour accéder aux tuiles... (à vérifier)

Apparemment, pour un "static map" il faut utiliser "Bing Maps REST Services."
et la clé est obligatoire pour l'API REST de Bing map:
http://msdn.microsoft.com/en-us/library/ff428642.aspx

Comment récupérer une tuile directement par son n° de tuile ???
Quelle que soit l'API, je n'ai vu que des repères longitude/latitude pour désigner le centre de la tuile ou éventuellement les coins extrêmes (bounding-box)...

A titre d'illustration j'ai utilisé le projet OSM Static maps API v0.3 pour récupérer des tuiles (http://wiki.openstreetmap.org/wiki/Static_map_images).

Voilà la carte globale à 256x256 pixels, tuile TMS(0,0) zoom 0:
http://pafciu17.dev.openstreetmap.or...85.0511&zoom=0

Et voilà la tuile TMS(2,2) zoom 2:
http://pafciu17.dev.openstreetmap.or...32,90,0&zoom=2

En règle générale, comment éviter que l'échelle soit affichée ?
Comment éviter le marquage "publicitaire" ?

[courdi95]

Tu peux récupérer les dalles une à une comme indiqué ici :
http://developer.mapquest.com/web/products/open/map

avec comme exemples (on retrouve le zoom, les valeurs Tx et Ty des dalles :zoom/Tx/Ty) :
http://otile1.mqcdn.com/tiles/1.0.0/...5240/12661.jpg

http://otile1.mqcdn.com/tiles/1.0.0/...5240/12661.jpg (remarque : en Europe/France le zoom max est de 11, pas terrible ...)

http://a.tile.openstreetmap.org/15/5240/12661.png

moins connu, des dalles topo (pour le trouver, il suffit de regarder dans Firefox Outils/Informations sur la page/Media):
http://toolserver.org/tiles/hikebike/12/2208/1372.png

ou encore des dalles BING :
http://ecn.dynamic.t1.tiles.virtuale...=hill&n=z&cb=1 (visiblement pas de clé dans la requête !!)

voir Yahoo (mais là on dirait qu'il y a une clé ...)
http://2.maps.nlp.nokia.com/maptile/...YRoc4RfxVo0Z4B

[OnePoint]

@courdi95: Merci pour les liens !

ou encore des dalles BING :
http://ecn.dynamic.t1.tiles.virtuale...=hill&n=z&cb=1 (visiblement pas de clé dans la requête !!)

Très bien ce lien !
http://ecn.dynamic.t1.tiles.virtualearth.net/comp/ch/12022001101?mkt=fr-fr&it=G,VE,BX,L,LA&shading=hill&n=z&cb=1

On peut y lire "en clair" le code pour désigner la tuile: 12022001101.
Quant aux autres paramètres... mystère

Et ce n'est pas Bing Maps...
C'est son ancêtre, Virtual Earth, une API plus ancienne, sans clé effectivement, mais qui ne sera peut être plus très longtemps opérationnelle.

D'ailleurs, je n'ai pas trouvé beaucoup d'information "officielle" pour récupérer une dalle via une requête HTTP avec Virtual Earth.

A tout hasard, un lien vers un article intéressant d'un blog en français :
"Google Maps, Virtual Earth et Yahoo! Maps : récupérer les images à la source"
http://royale.tiblog.fr/mars-2008/go...la-source.html

[EDIT]

Pour Virtual Earth...

Une adresse web plus simple avec le type d'image qui préfixe la clé de la dalle (tuile).
Type d'image: a=vue aérienne, r=route, h=piste cyclable.

http://tiles.virtualearth.net/tiles/r12022001101?mkt=fr-fr&g=117

Il existe aussi des groupe d'adresses de serveur qui fonctionnent. Je crois que l'objectif de ces multiples adresses vise simplement une limitation des navigateurs web qui ne permettent pas de solliciter n requêtes simultanées sur le même serveur. Donc ces adresses sont des alias pour contourner la limitation.

pour t0 à t8
http://t1.tiles.virtualearth.net/tiles/r12022001101.png?mkt=fr-fr&g=117

pour r0 à r3
http://r1.ortho.tiles.virtualearth.net/tiles/r12022001101.png?g=117&shading=hill

Et pour le fun...

Affichage de 6 tuiles Virtual Earth 256x256px obtenues directement à partir des adresses http://t*.tiles.virtualearth.net
12022001100 | 12022001101 | 12022001110
12022001102 | 12022001103 | 12022001112




[/EDIT]