Astuces DotNet (Sébastien Courtois)

05/05/2009

Introduction à Small Basic en français.

Classé dans : .NET, Débutant, Small Basic — Mots-clefs :, , , , , , — sebastiencourtois @ 09:21

Après plusieurs semaines de travail, une équipe de MSP a traduit la documentation anglaise de Small Basic en français.

Pour ceux qui ne connaissent pas Small Basic, il s’agit un projet de Microsoft fournissant aux débutants en programmation un environnement simple pour commencer doucement dans ce monde parfois obscur. Avec une syntaxe proche du Visual Basic, ce langage contient de nombreuses classes simplifiées fournissant facilement les fonctionnalités réellement nécessaires aux débutants.

SB

Petit tour de l’équipe qui a réalisé la traduction :

Au passage, un grand merci à Florie Perouze de l’équipe Education de Microsoft France qui nous a permis de réaliser ce projet.

Site officiel Small Basic

Blog officiel Small Basic

Documentation Français

24/04/2009

[Virtual Earth] Développement Microsoft Virtual Earth Web Services – Part 4 : Route Service

Classé dans : .NET, Débutant, Virtual Earth — Mots-clefs :, , , , , — sebastiencourtois @ 15:01

Liens des posts précédents :

  1. Introduction à Microsoft Virtual Earth (Part 1)
  2. Géocoding / Géocoding Inverse (Part 2)
  3. Récupération des images satellites (Part 3)
  4. Calcul d’itinéraires (Part 4)

Suite de notre grande exploration du Web Service Virtual Earth. Aujourd’hui, nous allons nous intéresser au calcul d’itinéraire. Cette fonctionnalité de Virtual Earth permet de calculer le trajet entre une série de point de contrôles (Waypoints). Il est possible de régler les options du calcul d’itinéraire (type de déplacement, trajet le plus rapide, le plus court …).

Comme d’habitude, il faut ajouter faire “Add Service Reference” avec l’adresse : http://staging.dev.virtualearth.net/webservices/v1/routeservice/routeservice.svc 

Remarque : Afin de fonctionner, il est nécessaire régler certains paramètres WCF de ce service. Dans le fichier app.config (ou web.config ou encore ServiceReference.clientconfig selon le type de projet) de l’application, dans la partie contenant les Binding WCF, il faut trouver le binding lié à RouteService (en général : <binding name="BasicHttpBinding_IRouteService") puis modifier l’attribut maxReceivedMessageSize (mettre la valeur 9000000 à la place de celle par défaut) et l’attribut maxBufferSize (mettre la valeur 9000000 à la place de celle par défaut). Cela est du au fait que RouteService renvoie un nombre d’informations supérieur à ce dont WCF est habitué à manipuler.

Ce service contient une classe principale RouteServiceClient  qui contient deux méthodes :

      • CalculateRoute(RouteRequest request) : Calcul d’un itinéraire entre plusieurs points
      • CalculateRoutesFromMajorRoads(MajorRoutesRequest request) : Calcul d’itinéraires partant des routes principales vers un point d’arrivée spécifié (carte d’accès).

 


  • Calcul d’un itinéraire entre plusieurs points

Le calcul d’itinéraire entre plusieurs points à besoin de deux informations : Les points de passages et là façons de calculer le trajet. Ces deux informations sont contenues dans la classe RouteRequest qui sera passer en paramètre de la méthode CalculateRoute de RouteServiceClient.

Les points de passages doivent être fournis dans la propriété WayPoints de  RouteRequest. Cette propriété prend un tableau de WayPoint, un WayPoint n’étant composé que d’une localisation GPS (latitude/longitude/altitude) et d’une propriété Description pour donner un titre au point de passage.

Les options de calcul d’itinéraire se trouvent dans la propriété Options. Cette propriété est de type RouteOptions et contient les champs suivantes :

Nom de la propriété Description
Mode Type de déplacement.
Enumération TravelMode :
Driving : Voiture (par défaut)
Walking : A pied (ne marche pas pour tous les pays)
Optimization Méthode de calcul du trajet. Marche en combinaison avec TrafficUsage
Enumération RouteOptimization :

MinimizeDistance : Distance minimale
MinimizeTime : Temps minimal

RoutePathType Type de données brutes renvoyées (en plus des données d’itinéraires)
Enumération RoutePathType :
None : Aucune donnée (par défaut)
Points : Un ensemble de points décrivant le chemin de la route.
TrafficUsage Type d’adaptation du trajet en fonction du trafic
Enumération TrafficUsage :

None : On ne tient pas compte du trafic (par défaut)

TrafficBasedRouteAndTime : On change le trajet pour minimiser le temps si nécessaire

TrafficBasedTime : On ne change pas la route mais on tient compte du trafic lors du calcul du trajet.

Combinaisons de Optimization et TrafficUsage :

Optimization TrafficUsage Description

MinimizeDistance

None

Trajet le plus direct (en distance) sans prendre en compte le trafic.

MinimizeDistance

TrafficBasedRouteAndTime

Une Exception lancée. Je pense que c’est du au fait que changer la route d’un trajet le plus direct en fonction du trafic => trajet plus long => incohérence.

MinimizeDistance

TrafficBasedTime

Trajet le plus direct (en distance) en tenant compte du trafic dans les calculs de durée (le trajet n’est pas changé… on passera dans les bouchons quand même :) ).

MinimizeTime

None

Trajet le plus rapide (en temps) sans prendre en compte le trafic.

MinimizeTime

TrafficBasedRouteAndTime

Trajet le plus rapide (en temps) en tenant compte du trafic et en le modifiant le cas échéant.

MinimizeTime

TrafficBasedTime

Trajet le plus rapide (en temps) en tenant compte du trafic dans les calculs de temps de trajet (la route n’est pas modifié en fonction du trafic).

Un petit code vaut mieux qu’un long discours : (les variables positionWinwise, positionMSFUniv, positionMSF sont des coordonnées géographiques calculées avant ce code)

RouteServiceClient rsc = new RouteServiceClient();
RouteRequest rq = new RouteRequest();
rq.Credentials = new VETutorial.RouteService.Credentials();
rq.Credentials.Token = token;
rq.Culture = "fr-FR";
rq.Waypoints = new Waypoint[]
{
	new Waypoint()
	{
		Description = "Winwise (Départ)",
		Location = new VETutorial.RouteService.Location()
		{
			Longitude = positionWinwise.Longitude,
			Latitude = positionWinwise.Latitude,
		}
	},
	new Waypoint()
	{
		Description = "Microsoft France (Rue de l'université)",
		Location =  new VETutorial.RouteService.Location()
		{
			Longitude = positionMSFUniv.Longitude,
			Latitude = positionMSFUniv.Latitude,
		}
	},
	new Waypoint()
	{
		Description = "Microsoft France (Rue du québec)",
		Location =  new VETutorial.RouteService.Location()
		{
			Longitude = positionMSF.Longitude,
			Latitude = positionMSF.Latitude,
		}
	},
};
rq.Options = new RouteOptions()
{
	Mode = TravelMode.Driving,
	Optimization = RouteOptimization.MinimizeTime,
	RoutePathType = RoutePathType.Points,
	TrafficUsage = TrafficUsage.TrafficBasedRouteAndTime,
};
RouteResponse routeResult = rsc.CalculateRoute(rq);

Comme vous pouvez voir dans ce code, on peut définir des informations supplémentaires comme les données d’authentifications ou encore la culture (langue) du résultat.

En réponse à l’appel de la méthode CalculateRoute, on obtient une classe de réponse de type RouteResponse contenant un champ ResponseSummary (déjà décrit dans les posts précédents) et un champ Result de type RouteResult contenant les informations sur le trajet.

La classe RouteResult fonctionne en arborescence :

Un RouteResult contient des Legs: Un Leg  est un trajet entre deux points de passages. Si plusieurs points de passages alors plusieurs Legs dans le RouteResult

Un Leg contient un tableau d’ItineraryItem (dans la propriété Itinerary) : Un ItineraryItem contient les informations entre deux changements de directions.

Chaque RouteResult, Leg et ItineraryItem contient une propriété Summary contenant le rectangle de leur localisation (propriété BoundingRectangle) ainsi que le temps de parcours en secondes (propriété TimeInSeconds) et la longueur de ce parcours dans la propriété Distance (par défaut en KM mais réglable dans la propriété UserProfile de la requête).

En dehors de ces données, la classe RouteResult contient aussi les données brutes du chemin dans la propriété RoutePath. Il contient un tableau de points géographiques représentant le trajet à faire. Cette propriété est la raison pour laquelle les données renvoyés par le service sont énormes. N’activer cette propriété que si nécessaire (désactivé par défaut : propriété RoutePathType de la requête).

La classe Leg a aussi deux propriétés spécifiques : ActualStart, ActualEnd. Ces propriétés indiquent les positions géographiques de départ et d’arrivés du Leg.

La classe ItineraryItem contient les propriétés suivantes :

Nom de la propriété Description
CompassDirection Orientation du déplacement (chaines de caractères “Nord” …)
Hints Indication permettant de mieux repérer le changement de direction (exemple : “la rue précédente est …”)
Location Position du changement de direction
ManeuverType Type de changement (tourner à gauche, droite, demi tour …)
Text Texte en format XML indiquant le changement à faire (Exemple : “<VirtualEarth:Action>Quitter</VirtualEarth:Action> <VirtualEarth:RoadName>Rue Gaillon</VirtualEarth:RoadName>”)
Warnings Danger sur la route. Lié aux infos traffic, cette propriété indique s’il y a un évènement sur votre trajet (accident, travaux …)

Voici le code d’affichage d’un trajet :

Console.WriteLine("--- Itinéraire  ---");
Console.WriteLine("Temps de calcul : "+ sw.Elapsed);
int i = 1;
foreach (var leg in routeResult.Result.Legs)
{
	var duree = new TimeSpan(0,0,(int)leg.Summary.TimeInSeconds);
	Console.WriteLine("-----    Partie " + i + " ------");
	Console.WriteLine("De (" + leg.ActualStart.Latitude +","+leg.ActualStart.Longitude+") à (" + leg.ActualEnd.Latitude +","+leg.ActualEnd.Longitude+")");
	Console.WriteLine("Distance " + leg.Summary.Distance + " km");
	Console.WriteLine("Temps estimé : " + duree.Hours + " h " + duree.Minutes + " min " + duree.Seconds+ " sec");
	Console.WriteLine("************ TRAJET ************");
	int j = 1;
	double distanceDone = 0;
	foreach (var turn in leg.Itinerary)
	{
		var duree2 = new TimeSpan(0, 0, (int)turn.Summary.TimeInSeconds);
		string HumanInfos = StripXMLFromText(turn.Text);
		Console.WriteLine("Indication " + j + " " + (distanceDone) + " km ["+duree2.Hours+":" + duree2.Minutes + ":" + duree2.Seconds+ "] : " + HumanInfos);
		distanceDone += turn.Summary.Distance;
		j++;
	}
	Console.WriteLine("----- Fin Partie " + i + " -----");
	i++;
}

Le résultat obtenu est le suivant :

— Itinéraire  —

Temps de calcul : 00:00:04.3373465

—–    Partie 1 ——

De (48,868681,2,334231) à (48,861122,2,309237)

Distance 2,788 km

Temps estimé : 0 h 7 min 46 sec

************ TRAJET ************

Indication 1 0 km [0:0:11] : Quitter Rue Gaillon

Indication 2 0,13 km [0:0:49] : Prendre à gauche Avenue de l’Opéra

Indication 3 0,156 km [0:0:53] : Tourner à droite Rue Saint-Roch

Indication 4 0,569 km [0:1:17] : Tourner à droite Rue de Rivoli

Indication 5 1,215 km [0:0:5] : Continuer tout droit Place de la Concorde

Indication 6 1,257 km [0:0:9] : Continuer à gauche Place de la Concorde

Indication 7 1,338 km [0:0:58] : Au rond-point prendre 4

Indication 8 1,61 km [0:0:57] : Prendre à droite Pont de la Concorde

Indication 9 1,835 km [0:1:17] : Tourner à droite Quai d’Orsay

Indication 10 2,531 km [0:0:6] : Continuer à droite Quai d’Orsay

Indication 11 2,584 km [0:0:2] : Tourner à gauche Quai d’Orsay

Indication 12 2,61 km [0:0:56] : Continuer tout droit Rue Surcouf

Indication 13 2,777 km [0:0:6] : Tourner à droite Rue de l’Université

Indication 14 2,788 km [0:0:0] : Arrivée Microsoft France (Rue de l’université)

—– Fin Partie 1 —–

—–    Partie 2 ——

De (48,861122,2,309237) à (48,6900826,2,2157051)

Distance 33,094 km

Temps estimé : 0 h 33 min 46 sec

************ TRAJET ************

Indication 1 0 km [0:0:36] : Quitter Rue de l’Université

Indication 2 0,28 km [0:0:28] : Tourner à droite Rue Malar

Indication 3 0,439 km [0:1:9] : Tourner à gauche Quai d’Orsay

Indication 4 0,685 km [0:2:26] : Continuer tout droit Quai Branly

Indication 5 2,079 km [0:1:27] : Le nom de la voie change Quai de Grenelle

Indication 6 2,877 km [0:2:34] : Le nom de la voie change Quai André Citroën

Indication 7 4,109 km [0:0:33] : Au rond-point prendre 1

Indication 8 4,378 km [0:0:55] : Le nom de la voie change Quai d’Issy-les-Moulin

eaux

Indication 9 4,925 km [0:5:21] : Voie Ad/15 prendre à gauche Boulevard Périphéri

que Lyon

Indication 10 10,008 km [0:2:57] : Prendre à droite E15 Nantes-Bordeaux/Aéroport

Orly-Rungis/Évry-Lyon

Indication 11 12,67 km [0:2:14] : Prendre à droite E15 Véhicules Lents-Toutes Di

rections

Indication 12 15,678 km [0:2:11] : Continuer à gauche E15

Indication 13 19,625 km [0:7:10] : Prendre à droite E5/E50

Indication 14 30,882 km [0:0:54] : 9 prendre à droite Chartres Par RN/Les Ulis/Z

.A. de Courtaboeuf/Villejust

Indication 15 31,465 km [0:0:31] : Prendre à droite D118

Indication 16 31,913 km [0:0:15] : Prendre à droite

Indication 17 32,063 km [0:0:36] : Tourner à droite Avenue de la Baltique

Indication 18 32,32 km [0:1:29] : Tourner à droite Avenue du Québec

Indication 19 33,094 km [0:0:0] : Arrivée Microsoft France (Rue du québec)

—– Fin Partie 2 —–

J’avoue que c’est moins sexy qu’une belle carte en 3D avec le chemin en surbrillance mais c’est mieux que rien. Je vais essayer de voir comment afficher ce trajet sur une carte (avec le RoutePath de RouteResult je pense). Sujet d’un prochain post.


  • Calcul d’itinéraires depuis des routes principales

Le principe de la méthode CalculateRoutesFromMajorRoads est de fournir les trajet allant (ou revenant) d’un point nommé Destination vers les grands axes routiers. Au niveau de la requête, la plupart des propriétés décrites ci dessus fonctionnent avec la classe MajorRoutesRequest. Deux différences toutefois :

La propriété Waypoints disparait au profit d’une propriété Destination ne permettant de définir qu’un WayPoint.

La propriété Options devient du type MajorRoutesOptions et cela ajoute un nouveau paramètre d’options : la propriété booléenne ReturnRoutes indique si on souhaite calculer les routes entre la destination et les routes majeurs (true) où si l’on souhaite uniquement les points d’entrées sur les routes majeures les plus proches (false. valeur par défaut).

MajorRoutesRequest mrr = new MajorRoutesRequest();
mrr.Credentials = new VETutorial.RouteService.Credentials();
mrr.Credentials.Token = token;
mrr.Destination = new Waypoint()
{
	Description = "Winwise (Départ)",
	Location = new VETutorial.RouteService.Location()
	{
		Longitude = positionWinwise.Longitude,
		Latitude = positionWinwise.Latitude,
	}
};
mrr.Culture = "fr-FR";
mrr.Options = new MajorRoutesOptions()
{
	Mode = TravelMode.Driving,
	Optimization = RouteOptimization.MinimizeTime,
	RoutePathType = RoutePathType.Points,
	TrafficUsage = TrafficUsage.TrafficBasedRouteAndTime,
	ReturnRoutes = true
};
MajorRoutesResponse MRresult = rsc.CalculateRoutesFromMajorRoads(mrr);

Au niveau de la réponse, on reste sur les mêmes types de données. On a ainsi la propriété Routes contenant des RouteResult (décrit plus haut) donnant les itinéraires entre le point destination et une route majeure. La propriété StartingPoints est un tableau de positions géographiques indiquant les entrées sur les routes majeures environnantes.

Ici se conclut ce post sur les calculs d’itinéraire sous Virtual Earth. Il ne reste plus qu’un service à découvrir : Le SearchService puis nous terminerons par une belle application WPF reprenant tout ce que l’on a appris aux cours de ces 5 posts.

N’hésitez pas à mettre des commentaires pour enrichir ces tutoriaux.

08/04/2009

[Virtual Earth] Utilisation des services web Virtual Earth derrière un proxy

Classé dans : .NET, Débutant, Virtual Earth — Mots-clefs :, , , , , — sebastiencourtois @ 16:17

Si, comme moi, vous travaillez sur Virtual Earth derrière un proxy d’entreprise, il y a un moyen de fournir les informations nécessaire pour laisser passer les requêtes Virtual Earth.

Pour cela, on utilise la classe WebProxy :

CommonService common = new VETutorial.TokenService.CommonService();
common.Credentials = new NetworkCredential("VE_login", "VE_password");

WebProxy wbproxy = new WebProxy("Url du proxy",8080); // 8080 est le port d'écoute du proxy dans mon exemple
wbproxy.Credentials = new NetworkCredential("Login pour le proxy", "Password pour le proxy");

common.Proxy = wbproxy;

Si on ne fait pas cette manipulation, on récupère une erreur 407 avec une WebException nous annonçant que nous ne sommes pas authentifiés sur le proxy. (Message exact: “The request failed with HTTP status 407: Proxy Authentication Required.”).

En espérant que cela vous servira :)

[Virtual Earth] Développement Microsoft Virtual Earth Web Services – Part 3 : Imagery Service

Classé dans : Débutant, Virtual Earth — Mots-clefs :, , , , , , — sebastiencourtois @ 16:00

Liens des posts sur le sujet sur ce blog :

  1. Introduction à Microsoft Virtual Earth (Part 1)
  2. Géocoding / Géocoding Inverse (Part 2)
  3. Récupération des images satellites (Part 3)
  4. Calcul d’itinéraires (Part 4)

Dans ce post, nous allons parler la partie la plus intéressante de Virtual Earth : La récupération des images satellites.

Tout d’abord, il est nécessaire d’ajouter une référence vers le service d’imagerie de Virtual Earth : http://staging.dev.virtualearth.net/webservices/v1/imageryservice/imageryservice.svc. On instancie ensuite une classe proxy nommée ImageryServiceClient afin d’avoir accès au service.

ImageryServiceClient imagerySvc = new ImageryServiceClient();

On peut utiliser ce service pour récupérer les images de deux manières : Récupération des images à la demande et Récupération des images à la volée (Tiles).

  • Récupération des images à la demande : MapUriRequest

Il est possible de récupérer des images satellites en fournissant des coordonnées géographiques puis de spécifier des informations supplémentaires pour avoir l’image souhaitée.

On utilise pour cela la classe MapUriRequest que l’on va fournir en paramètre de la méthode GetMapUri de la classe ImageryServiceClient.

Cette classe MapUriRequest est composée des propriétés spécifiques suivantes : (je ne mets que les propriétés spécifiques aux requêtes MapUri. Pour les autres paramètres, voir les posts précédents).

Nom de la propriété Description
Center Coordonnées géographiques du point central de l’image (classe Location avec des propriétés Latitude/Longitude/Altitude)
MajorRoutesDestination Paramètre ne fonctionnant pas chez moi et dont je ne comprends pas l’intérêt. Voir la documentation MSDN.
Options Options de paramétrage de l’image sous la forme d’une classe MapUriOptions. Cette classe est décrite par la suite.
Pushpins Ajout de puce pour indiquer les emplacements importants. Il s’agit d’un tableau de Pushpin. Il est possible de définir, pour chaque puce, sa position, son nom ainsi que l’icône à utiliser parmi une liste prédéfini par Microsoft (Liste des icones disponible par défaut). Le nombre maximum d’icones est de 10 par image.
    • MapUriOptions

La classe MapUriOptions permet de définir un certain nombre de paramètres sur l’image que l’on souhaite obtenir.

Nom de la propriété Description
DisplayLayers Il est possible de superposer sur l’image des calques d’informations. Pour cela, il suffit de fournir une chaine de caractères contenant la liste des calques disponibles.
ImageSize Taille de l’image souhaitée (valeurs entre 80 et 830 pixels sur les deux dimensions)
ImageType Format de l’image (GIF, JPEG, PNG). Par défaut, cela dépend du style de carte voulue. (voir la documentation MSDN)
PreventIconCollision Valeur booléen pour indiquer si l’on souhaite que les icones (pushpins) se superposent lorsqu’ils sont proche.
Style Type de carte parmi les suivantes : Route (Road), Aérien (Aerial), Aérien avec titre (AerialWithLabels).

Les images de type  Birdseye et BirdseyeWithLabel ne sont pas disponible sur le Web Service.
UriScheme Type d’URL : HTTP ou HTTPS
ZoomLevel Niveau de zoom compris entre 1 et 21. (1 étant le plus éloigné et 21 étant le plus proche de la cible).
    • Un exemple d’utilisation

N.B : Les variables positions et token sont reprises des exemples précédents.

MapUriRequest mapUriRequest = new MapUriRequest();
mapUriRequest.Credentials = new VETutorial.ImageryService.Credentials();
mapUriRequest.Credentials.Token = token;

mapUriRequest.Center  = new VETutorial.ImageryService.Location() { Latitude = position.Latitude, Longitude = position.Longitude };
mapUriRequest.Options = new MapUriOptions()
{
	ImageSize = new VETutorial.ImageryService.SizeOfint() {  Width=800, Height = 600},
	ImageType = ImageType.Jpeg,
	Style = MapStyle.AerialWithLabels,
	UriScheme = UriScheme.Https,
	ZoomLevel = 18
};
mapUriRequest.Pushpins = new Pushpin[] { new Pushpin() { Location = new VETutorial.ImageryService.Location() { Latitude = position.Latitude, Longitude = position.Longitude } } };

MapUriResponse reponseMapUrl = imagerySvc.GetMapUri(mapUriRequest);
string finalUrl = reponseMapUrl.Uri.Replace("{token}",token);

L’exemple ci-dessus, crée une requête MapUri et lui indique le token d’authentification à utiliser (ne pas oublier cette étape). On définit ensuite les différents paramètres comme la position centrale, taille et format de l’image et niveau de zoom. Après l’appel de la méthode GetMapUri, on obtient un objet MapUriResponse contenant une propriété Uri contenant un modèle d’URL pour récupérer l’image. Ce modèle permet de construire soit même l’url pour récupérer l’image.

Dans mon cas, je reçois l’url suivant : https://staging.tiles.virtualearth.net/api/GetMap.ashx?c=48.868681,2.334231&ppl=48.868681,2.334231&w=800&h=600&o=jpeg&b=h,mkt.en-US&z=18&token={token}

Sans rentrer dans les détails des différentes paramètres contenues dans cette url, nous nous intéresserons sur le dernier paramètre : &token={token}. Au sein des services Virtual Earth, le modèle URL contiennent des zones “à remplacer” toujours représenté par des {}. Dans ce cas précis, il faut remplacer le {token} par la valeur de notre token. La façon la plus simple pour remplacer ces zones est d’utiliser la méthode Replace de la classe String. On arrive finalement à une adresse finale qui pourra être utilisé dans un navigateur, WebClient ou autres pour récupérer l’image.

L’image obtenue est la suivante : GetMap

  Un des trucs sympas est que l’on peut mettre cet adresse sur la propriété Source des contrôles d’images (Winforms,ASP.NET …) et l’image est téléchargée directement et affichée.

  • Récupération des images à la volée (Tiles)

Demander à Virtual Earth de générer une image pour nous est pratique. Toutefois, il y a un certain cout en termes de performance qui fait que cela n’est utilisable que pour afficher des images ponctuellement. Un déplacement fluide sur une carte avec l’API MapURI n’est pas envisageable. C’est pourquoi Virtual Earth fournit une autre façon de récupérer des images : Le Tile System.

    • Qu’est ce que le Tile System ?

Un Tile est une image d’une taille fixe représentant une partie d’une image plus grande. Dans le cas de la cartographie, ces images représentent un morceau du monde et, une fois l’ensemble de ces Tiles assemblés, on obtient une image du monde. Au sein de Virtual Earth, ces Tiles font 256×256 pixels. Le nombre de Tiles représentant le monde dépend du zoom. Au zoom le plus haut, on a 4 Tiles. Au zoom suivant on a 16 Tiles et ainsi de suite. Chaque Tile est numéroté en fonction de son emplacement et son zoom. Ce concept est décrit par le schéma suivant :

tilesystem

Afin d’obtenir chacune des images, il est nécessaire de construire l’url vers l’image. On obtient l’url d’un Tile de la façon suivante :

https://staging.tiles.virtualearth.net/tiles/{type}{code}.jpeg?g={version}&mkt={culture}&token={token}

Nom Description
{type} Type de carte représenté par un caractère : h pour Hybrid (Aérien avec textes), a pour Aerial (Aérien), r pour Road (Carte routière)
{code} Identifiant du tile comme décrit dans le schéma ci-dessus
{version} Numéro de version de Virtual Earth (275 au moment de l’écriture de ce tutorial)
{culture} Culture à utiliser dans l’affichage du texte (‘en-US’, ‘fr-FR’ …)
{token} Token d’authentification

Exemple : https://staging.tiles.virtualearth.net/tiles/h0331.jpeg?g=275&mkt=fr-FR&token=12345  

h0331

    • Informations sur les Tiles

Il est possible d’avoir des informations d’un Tile en fonction de son emplacement (coordonnées géographiques). Pour cela, on utilise la classe ImageryMetadataRequest. Cette classe contient les  mêmes propriétés que la classe MapUriRequest décrit plus haut. La seule différence se trouve dans la propriété Options qui est une classe ImageryMetadataOptions. Elle contient les propriétés suivantes :

Nom de la propriété Description
Heading Orientation de la carte ( 0° = Nord en haut)
Location Centre de la carte (coordonnées géographiques)
ReturnImageryProviders Booléen indiquant si l’on souhaite récupérer les données sur les fournisseurs des cartes (copyrights …)
UriScheme Type d’URL : HTTP ou HTTPS
ZoomLevel Niveau de zoom
ImageryMetadataRequest metadataRequest = new ImageryMetadataRequest();
metadataRequest.Credentials = new VETutorial.ImageryService.Credentials();
metadataRequest.Credentials.Token = token;

metadataRequest.Style = MapStyle.AerialWithLabels;
metadataRequest.Options = new ImageryMetadataOptions()
{
	Heading = new VETutorial.ImageryService.Heading() { Orientation = 0 } ,
	Location = new VETutorial.ImageryService.Location() { Latitude = position.Latitude, Longitude = position.Longitude },
	ZoomLevel = 8,
	ReturnImageryProviders = true,
	UriScheme = UriScheme.Https
};

ImageryMetadataResponse resultImageMetadata = imagerySvc.GetImageryMetadata(metadataRequest);

En réponse de la méthode GetImageryMetadata, on récupère une classe  ImageryMetadataResponse  contenant une propriété Result étant représenté par un tableau de ImageryMetadataResult celui-ci contient les informations suivantes :

Nom de la propriété Description
ImageryProvider Liste des fournisseurs de données
ImageSize Taille de l’image (normalement 256×256 pixels)
ImageUri Schéma de l’URL pour récupérer l’image (voir plus loin dans ce post)
ImageUriSubDomains Liste des sous domaines disponible pour cette image
Vintage Date de validité des images
ZoomRange Zoom lié à l’image

L’une des informations importantes de cette structure de données est ImageUri. Il est nécessaire de la modifier comme décrit ci-dessus. Ainsi, dans mon exemple, on obtient : https://t1.staging.tiles.virtualearth.net/tiles/h12022001.jpeg?g=275&mkt={culture}&token={token}. Il suffit de remplacer {culture} et {token} pour avoir accès à l’image centrée sur la propriété Location définie dans la requête.

Ainsi se conclut la description du service d’imagerie de Virtual Earth. Comme certains d’entre vous l’auront remarqué, il manque de nombreuses fonctionnalités comme le BirdEye ou la 3D. Cela est du au fait que les services Web Virtual Earth ne sont pas aussi complète que le contrôle ASP.NET. Ces fonctionnalités arriveront par la suite.

Dans les prochains posts nous parlerons du service de calcul d’itinéraire ainsi que du moteur de recherche d’entités (magasins, écoles, points d’intérêt …) de Virtual Earth. Je vais aussi faire une démo intégrant l’ensemble des services décrit afin de montrer les possibilités de Virtual Earth de façon plus parlante. Cette démo sera surement en WPF ou en Silverlight (selon mes envies du moment).

N’hésitez pas à me faire des retours sur ces posts. Si vous avez des idées de sujets à traiter pour ce blog, merci de les indiquer dans les commentaires ci-dessous.

07/04/2009

[Virtual Earth] Développement Microsoft Virtual Earth Web Services – Part 2 : Géocoding Service

Classé dans : .NET, Débutant, Virtual Earth — Mots-clefs :, , , , — sebastiencourtois @ 20:40

Cet article est une suite de l’article se trouvant ici. Il était question de créer un compte Virtual Earth et se connecter en C# aux différents services Web de Virtual Earth.

Liens des posts sur le sujet sur ce blog :

  1. Introduction à Microsoft Virtual Earth (Part 1)
  2. Géocoding / Géocoding Inverse (Part 2)
  3. Récupération des images satellites (Part 3)
  4. Calcul d’itinéraires (Part 4)

L’article courant va parler de l’utilisation de un de ces services : Le Géocoding/Géocoding inverse.

Géocoding

Comme expliqué dans l’article précédent, le Géocoding est le processus permettant de retrouver des coordonnées géographiques d’un lieu à partir d’informations sur celui-ci (nom,adresse postale…). Un service de Virtual Earth est entièrement dédié à cette tache : Le GeocodeService.

Afin d’accéder aux informations de ce service, il faut d’abord générer la classe proxy permettant de communiquer avec ce service. Ce service étant un service WCF, il suffit d’ajouter la référence de service suivante (“Add Service Reference”) à votre projet : http://staging.dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc (nous travaillons toujours dans l’environnement de test).

Un fois la référence rajoutée, vous devriez avoir accès aux classes suivantes :

  • GeocodeServiceClient : Classe proxy principale gérant la connexion avec le service
  • GeocodeRequest : Classe permettant de fournir les données pour une requête de Géocoding
  • GeocodeResponse : Classe contenant les informations renvoyés par le service suite à un requête de Géocoding ou de Géocoding inverse.
  • ReverseGeocodeRequest : Classe permettant de fournir les données pour une requête de Géocoding inverse.

Fonctionnement générale d’une requête de Géocoding

Avant de commencer, il est nécessaire d’avoir un token d’authentification valide (voir le tutorial précédent). Ensuite, on utilise le code suivant :

GeocodeServiceClient geoCodeSvc = new GeocodeServiceClient();
GeocodeRequest geoCodeRequest = new GeocodeRequest();
geoCodeRequest.Credentials = new Credentials();
geoCodeRequest.Credentials.Token = token;
geoCodeRequest.Query = "Paris";
GeocodeResponse result = geoCodeSvc.Geocode(geoCodeRequest);

On crée le proxy vers le service de Géocoding en utilisant le constructeur par défaut. On crée ensuite une requête de Géocoding. On lui fournit les données d’authentification au travers de la propriété Credentials de la requête. On remplit la donnée token afin de prouver notre identité au serveur Virtual Earth. On remplit ensuite les données qui seront utilisées pour la requête (on utilise ici la propriété Query par simplicité, mais nous verrons plus loin qu’il y a beaucoup plus de possibilités). La requête proprement dite se réalise par la méthode Geocode de la classe proxy GeocodeServiceClient en lui fournissant les données de la requête. On récupère le résultat dans une classe GeocodeResponse.

Découverte de la classe GeocodeRequest

Pierre angulaire du système de Géocoding, la classe GeocodeRequest regroupe de nombreuses propriétés permettant d’affiner sa recherche géographique au maximum.

  • Query

La propriété la plus simple est la propriété Query. Cette propriété est une chaine de caractères dans laquelle il est possible de rentrer plusieurs mot clés (nom de pays,ville …). Cette propriété sera ensuite comparé par Virtual Earth avec la base de données d’entités géographiques afin de renvoyer les résultats les plus pertinents.

  • Options

Il est possible de restreindre ces résultats grâce à la propriété Options. Cette propriété possède une propriété Count permettant de définir le nombre maximal de réponses (5 par défaut). Il est aussi possible de définir des filtres (propriété Filters). Ces filtres permettent de supprimer des réponses en fonction de critères supplémentaires. Ces filtres/critères sont disponible au travers de classes spécialement conçues à cette effet. Ainsi si l’on souhaite n’avoir que les résultats avec une note de confiance forte, on utilisera le code suivant :

GeocodeService.ConfidenceFilter[] filters = new GeocodeService.ConfidenceFilter[1];
filters[0] = new GeocodeService.ConfidenceFilter();
filters[0].MinimumConfidence = GeocodeService.Confidence.High;
GeocodeService.GeocodeOptions geocodeOptions = new GeocodeService.GeocodeOptions();
geocodeOptions.Filters = filters; 

Le dernier paramètre, ExtensionData, de la propriété Options est lié à WCF et ne concerne pas ce tutorial.

  • Culture : Cette propriété permet de définir la langue dans laquelle vous souhaitez que les informations soient retournées. Par défaut, c’est l’anglais (‘en-US’).
  • ExecutionOptions : Cette propriété n’a qu’un booléen suppressFault. Par défaut à false, cette variable indique si vous souhaitez récupérer les erreurs Virtual Earth (false = je souhaite récupérer les erreurs).
  • UserProfile : Cette propriété permet de définir des informations sur l’utilisateur courant. On peut ainsi donner les informations concernant sa position, son déplacement, s’il est sur un appareil mobile … Cela permet au serveur de choisir les informations à retourner afin qu’elle soit le plus proche possible de ce que souhaite l’utilisateur.
  • Address

Après Query, c’est la propriété la plus important de GeocodeRequest. Cette propriété permet de rentrer les informations pour trouver les coordonnées d’une adresse postale en fonction de critères tel que la rue, la ville, le pays, le code postal. Les informations peuvent être incomplètes (fournir le code postal uniquement avec l’adresse suffit à localiser le lieu par exemple). Un tableau sur le site MSDN décrit les données minimales à fournir pour avoir une localisation précise : http://msdn.microsoft.com/en-us/library/cc966788.aspx.

Attention : Au sein d’une requête GeocodeRequest, il faut remplir, au minimum, le champ Query ou le champ Address afin d’obtenir une réponse de la part du serveur. Les autres champs sont optionnels

Afin de tester tout cela, nous allons prendre l’exemple de l’emplacement du siège de ma société Winwise (Winwise – 16 rue Gaillon,75002 PARIS). Je souhaite un seul résultat et je veux qu’il soit “sûr à 100 %”. On écrit donc le code suivant :

GeocodeServiceClient geoCodeSvc = new GeocodeServiceClient();
GeocodeRequest geoCodeRequest = new GeocodeRequest();

geoCodeRequest.Credentials = new VETutorial.GeoCodeService.Credentials();
geoCodeRequest.Credentials.Token = token;

ConfidenceFilter[] filters = new ConfidenceFilter[1] { new ConfidenceFilter() { MinimumConfidence = VETutorial.GeoCodeService.Confidence.High } };
geoCodeRequest.Options = new GeocodeOptions() { Count = 1, Filters = filters};

geoCodeRequest.Address = new Address()
{
	AddressLine = "16 rue Gaillon",
	PostalCode = "75002",
	PostalTown = "Paris",
};

GeocodeResponse result = geoCodeSvc.Geocode(geoCodeRequest);

J’obtiens le résultat suivant : Longitude : 2.334231 Latitude : 48.868681 ce qui correspond bien à l’emplacement de notre société comme le montre cette image ci-dessous prise avec le service d’imagerie de Virtual Earth (sujet d’un prochain tutorial).

winwise

Analyse  de la classe GeocodeResponse

Nous allons maintenant apprendre à traiter la réponse de Virtual Earth suite à une requête de Géocoding. Cette réponse possède deux propriétés : ResponseSummary et Results.

  • ResponseSummary

Cette propriété regroupe les informations sur le déroulement de la requête. On retrouve les informations sur les droits (propriété Copyright), l’identifiant de la requête (propriété TraceId), le statut de la requête (propriété StatusCode) indiquant s’il y a eu une erreur durant la requête. Si c’est le cas, la propriété FaultReason donne l’erreur lancée du coté Virtual Earth. Enfin la propriété AuthentificationResultCode indique si les informations concernant l’authentification sont valide.

  • Results

C’est dans cette propriété que l’on retrouve les résultats de la requête proprement dite. Il s’agit d’un tableau de GeocodeResult où chacune des cases représente une réponse possible. La taille du tableau peut varier de 0 jusqu’au nombre fourni dans la propriété Count des options de la requête.

Chacun des GeocodeResult contient les informations suivantes :

    • L’adresse du point dans la propriété Address.
    • Les deux points géographiques (haut gauche et bas droit) permettant d’avoir la meilleure vue de ce que l’on souhaite voir (Propriété BestView)
    • Le niveau de confiance du résultat (Propriété Confidence)
    • Un représentation en chaine de caractères de la confiance du résultat (Propriété MatchCode)
    • Un nom pour le résultat (propriété DisplayName)
    • Le type d’entité ciblé par le résultat sous forme d’une chaine de caractère (propriété EntityType)
    • Des positions géographiques possibles pour le résultat (propriété Locations). Cette propriété contient aussi le type de calcul de calcul a été utilisé (généralement “Interpolation”).

Parlons un peu du géocoding inverse : ReverseGeocodeRequest

Bien que beaucoup moins utilisé que le Géocoding classique, le Géocoding inverse est le processus permettant de retrouver une adresse depuis des coordonnées géographiques. Pour cela, on utilise la classe ReverseGeocodeRequest. Celle ci contient les mêmes champs que GeocodeRequest décrit précédemment sauf Query et Address (ce qui est normal vu que ce n’est pas l’objet de la requête). En revanche, on remarque l’apparition d’une propriété Location sur laquelle on peut indiquer la latitude, longitude, altitude désiré.

ReverseGeocodeRequest rgr = new ReverseGeocodeRequest();
rgr.Credentials = new VETutorial.GeoCodeService.Credentials();
rgr.Credentials.Token = token;

rgr.Location = new VETutorial.GeoCodeService.Location() { Longitude = 2.334231, Latitude = 48.868681 };

GeocodeResponse result2 = geoCodeSvc.ReverseGeocode(rgr);

Le résultat de la requête est, comme pour le Géocoding, un GeocodeResponse.

La suite au prochain épisode …

Dans le prochain article, nous parlerons de la récupération de cartes (images) au travers du ImageryService. Un autre article est prévu sur le calcul d’itinéraire entre N points.

N’hésitez pas à me faire des commentaires sur ces articles (bons ou mauvais je m’en fiche du moment que c’est constructif et que ça me permet de faire des articles meilleurs à l’avenir).

18/03/2009

Silverlight 3 Beta SDK Released ….

Classé dans : Silverlight — Mots-clefs :, , , — sebastiencourtois @ 16:06

Le Mix 2009 se tient actuellement à Las Vegas et, pour commencer cette série de conférence, Scott Guthrie a annoncé la sortie du SDK de Silverlight 3 Beta 1.

D’après des sites que j’ai pu lire les SDK et même la MSDN serait déja disponible :) .

Au programme de Silverlight 3 : … pas beaucoup d’informations. Apparemment accélération graphique 3D ( mais pas comme WPF… juste pour des petits effets 3D type carrousels), Pixel Shader, Haute Définition pour les vidéos … je pense aussi des nouveaux contrôles et autres.

Les liens que j’ai trouvé sur le sujet (contient les liens pour télécharger la bête) :

http://arstechnica.com/microsoft/news/2009/03/silverlight-3-related-bits-start-to-arrive-early.ars

http://www.neowin.net/news/main/09/03/18/microsofts-silverlight-3-beta-sdks-released

Je n’ai pas encore eu le temps d’y toucher mais je m’y mets dès ce soir :)

[Silverlight 2] Les converters typés

Classé dans : Débutant, Intermediaire, Silverlight, WPF — Mots-clefs :, , , — sebastiencourtois @ 15:46

 

Ceux qui ont déjà touchés à Silverlight 2 ou à WPF ont été amené à utilisé les converters. En travaillant, je me suis aperçu qu’une partie du code que j’écrivais dans un converter était principalement de la vérification de type d’entrée et de sortie. La cause : Les converters ne sont pas typés. Cela est, je pense, une fonctionnalité voulue par Microsoft afin de rendre ce système le plus flexible possible. Toutefois, j’aime bien les choses typés et ce principe me dérangeait d’autant que, la plupart du temps, je voulais un type d’entrée spécifique et un type de sortie spécifique.

Il existe un attribut en WPF pour “gérer” ce problème : ValueConversionAttribute. Toutefois, l’utilisation de cet attribut est de l’ordre informatif et il ne réalise aucune vérification. Le texte qui suit est donc valable pour WPF et Silverlight.

Partons d’un converter classique : Le BoolToVisibilityConverter

Le principe de ce converter est de fournir un booléen en entrée qui va définir un System.Windows.Visibility en sortie.

Voici le code du converter classique : 

Blog7-1

Comme vous pouvez le remarquer, 14 lignes de code pour écrire ce converter et 8 ne concerne pas la conversion en elle même mais plus les vérifications de types. J’ai ainsi factoriser ce code dans une classe abstraite générique afin n’avoir plus QUE de la conversion de type au sein de mes converters.

Code de la classe générique abstraite mère :  (VType représente le type d’entrée. TType représente le type de sortie.)

Blog7-2

Par héritage, on obtient le BoolToVisibiltyConverter suivant :

Blog7-3

Le développeur n’a plus qu’à remplir les méthodes abstraites héritées de TypedConverter. Ces méthode seront correctement typés (que ce soit dans leur paramètres et dans leur valeur de retour). De plus, la vérification de type est garanti par la classe mère. Au sein de BoolToVisibilityConverter, on ne retrouve que le code de conversion.

Certains pourront dire que ce code ne sert à rien car il fait perdre la flexibilité de Silverlight 2 (qui est un de ses grands atouts). Même si cela est vrai, 90 % des cas d’utilisations des converters se réalise avec un type d’entrée bien défini et un type de sortie bien défini. Autant essayé de gagner de la lisibilité dans le code sur ces cas là. Pour des cas nécessitant plus de flexibilité, rien n’empêche d’utiliser le bon vieux IValueConverter.

EDIT 18/03/09 : Suite à des tests, j’ai découvert un petit bug sur le code du TypedConverter. En effet, l’héritage au niveau du TargetType n’était pas pris en compte.

Exemple : Si on crée un TypedConverter<object,object> (i.e un converter standard), et qu’on lui fournit un targetType de Visibility, on obtient l’exception : “le type de sortie doit être …”. En effet, Visibility n’est pas object. Toutefois, vu que Visibility hérite de object, on aimerait pouvoir passer ce type de donnée pour qu’il soit valider “par héritage”. Or le test recherche une différence entre deux System.Type sans regarder la hiérarchie des classes. J’ai donc modifié le code du TypedConverter :

public abstract class TypedConverter<VType,TType>  : IValueConverter
{
	public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
	{
		//Vérification du type d'entrée
		if (!(value is VType))
			throw new InvalidOperationException("La paramètre d'entrée doit être de type "+ typeof(VType));
		//Vérification du type de sortie
		if(!this.IsTargetType(targetType,typeof(TType)))
			throw new InvalidOperationException("La type de sortie doit être de type " + typeof(TType));
		return this.Convert((VType)value, culture);
	}

	public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
	{
		//Vérification du type d'entrée
		if (!(value is TType))
			throw new InvalidOperationException("La paramètre d'entrée doit être de type " + typeof(VType));
		//Vérification du type de sortie
		if (!this.IsTargetType(targetType, typeof(VType)))
			throw new InvalidOperationException("La type de sortie doit être de type " + typeof(TType));
		return this.ConvertBack((TType)value, culture);
	}

	protected abstract TType Convert(VType p, CultureInfo culture);
	protected abstract VType ConvertBack(TType p, CultureInfo culture);

	//Méthode recherchant un type correspondant dans la hierarchie des classes
	private bool IsTargetType(Type targetType, Type type)
	{
		while(targetType != null)
		{
			if (targetType == type)
				return true;
			targetType = targetType.BaseType;
		}
		return false;
	}
}

L’héritage est ainsi gérer par l’utilisation de la méthode IsTargetType qui remonte l’arborescence des classes de targetType jusqu’à trouver une classe correspondant au type demandé. Si ce n’est pas le cas, une exception est lancée.

12/03/2009

[Virtual Earth] Développement Microsoft Virtual Earth Web Services – Part 1

Classé dans : .NET, Débutant, Virtual Earth — Mots-clefs :, , , , , , , — sebastiencourtois @ 18:57

Au travers de mes stages et autres projets personnels, j’ai été amené à travailler avec des outils cartographiques divers (de Microsoft MapPoint à GoogleMap en passant par d’autres éditeurs dont je ne citerai pas le nom). Travaillant aujourd’hui majoritairement en environnement .NET, j’ai décidé de me pencher sur l’offre cartographique de Microsoft : Microsoft Virtual Earth.

Liens des posts sur blog:

  1. Introduction à Microsoft Virtual Earth (Part 1)
  2. Géocoding / Géocoding Inverse (Part 2)
  3. Récupération des images satellites (Part 3)
  4. Calcul d’itinéraires (Part 4)

Microsoft Virtual Earth ?

Virtual Earth est composé d’une série d’outils et de services Internet fournissant des informations cartographiques. Ces informations peuvent être de plusieurs types :

  • Images satellites
  • Du Géocoding : Traduire une adresse postale en coordonnées géographiques.
  • Géocoding Inverse : Traduire des coordonnées géographiques en adresse postale.
  • Moteur de recherche : A partir de données diverses, on récupère un ou plusieurs localisations (avec un degré de précision/confiance).
  • Calcul d’itinéraire : A partir de deux adresses/localisations, on récupère l’ensemble du chemin à effectuer en voiture (orientation lors des croisements, distance entre chaque croisement…).

Microsoft Virtual Earth : Comment ça marche ?

A l’inverse de Microsoft MapPoint où les données devait être stockés sur le poste client (ou sur des postes serveurs proche du client), les données de Virtual Earth sont stockées sur les datacenter Microsoft à travers le monde et l’utilisateur ne demande que les données qu’il souhaite visualiser.

Ces données ne sont pas accessible directement depuis les datacenters. Il faut passer par une couche de services Web pour y accéder. Il existe deux façons de faire :

  • Utilisation d’un contrôle ASP.NET Ajax fourni avec le SDK de Virtual Earth (démonstration : http://maps.live.com/)
  • Utilisation du Web Service Virtual Earth (SOAP over HTTP)

Blog6-1

Nous ne parlerons pas du contrôle ASP.NET dans ce tutorial. Vous pourrez trouver les informations voulues pour le développement avec ce type de contrôle à l’adresse suivante : http://dev.live.com/Virtualearth/sdk/

Microsoft Virtual Earth Web Service

Virtual Earth est composé de 5 Web Services :

  • Common (asmx) : Web Service contenant l’ensemble des données communes à tous les services Virtual Earth ainsi que les fonctions d’authentification et de sécurité.
  • Geocode Service (WCF) : Web Service de Géocoding/Géocoding Inverse.
  • Route Service (WCF) : Web Service de calcul d’itinéraire.
  • Imagery Service (WCF) : Web Service de récupération des images.
  • Search Service (WCF) : Web Service du moteur de recherche.

Microsoft Virtual Earth Web Service : Authentification

L’authentification à Virtual Earth se réalise en deux étapes :

  1. Le client fournit un couple login/password au Web Service Common.
  2. Si les informations sont correctes, le Web Service renvoie un token d’authentification sous la forme d’une longue chaine de caractères.

Les appels suivants à l’ensemble des Web Services  Virtual Earth se fera toujours en fournissant ce token.

Dans ce tutorial, nous allons voir comment récupérer un token d’authentification puis faire un appel à une fonction de Geocoding.

  • Récupération Login/Password sur la plateforme développeur Virtual Earth

Avant toute chose, il faut récupérer un couple login/password auprès de Microsoft. Pour cela, il faut une Windows Live ID (https://login.live.com).

Il faut ensuite se connecter sur la plateforme développeur Virtual Earth (https://mappoint-css.live.com/mwssignup) pour demander un compte “free evaluation developer account”. Ce type de compte est gratuit et comporte certaines limitations comme des images contenant des messages “Staging" au milieu des images satellites et une déconnexion automatique en cas d’un nombre trop important de requêtes (j’ai été très peu déconnecté pour ce motif en utilisant les services).

Une fois inscrit, aller dans “Manage account” pour récupérer votre “Account ID”  (i.e login) et pour définir votre mot de passe.

  • Configuration de la solution Visual Studio

Créer une nouvelle solution (selon le type de projet que vous souhaitez faire).

Nous allons ajouter une référence Web vers le Web Service Common. Cliquer droit sur le projet puis aller dans “Add Service Reference”. Au sein de cette fenêtre, cliquer sur “Advanced” en bas à gauche puis sur “Add Web Reference”. Indiquer dans URL l’adresse : https://staging.common.virtualearth.net/find-30/common.asmx?wsdl. Il est possible qu’une popup vous demande vos informations de login/password. Une fois validé, indiquer un nom pour la Web Reference (TokenService dans notre exemple) puis cliquer sur “Add Reference”. Il est à noter que cette opération est longue car le Web Service Common est un service asmx (ancienne génération).

Pour chacun des autres Web Service WCF, il suffit de faire “Add Service Reference” puis d’indiquer une des quatre adresses suivantes puis cliquer sur “GO” puis donner un nom de namespace (le nom des services dans la liste suivante est un convention de ma part) puis cliquer sur “Add Reference”:

Ne pas oublier d’inclure les lignes suivantes au début du code :

using VETutorial.TokenService;
using System.Net;

//Récupération de l'adresse locale
string ipadr = "127.0.0.1";
var host = Dns.GetHostEntry(Dns.GetHostName());
foreach (IPAddress ip in host.AddressList)
{
	if (ip.AddressFamily == System.Net.Sockets.AddressFamily.InterNetwork ||
	    ip.AddressFamily == System.Net.Sockets.AddressFamily.InterNetworkV6)
	{
		ipadr = ip.ToString();
	}
}
//Création du proxy d'accès au CommonService
CommonService common = new VETutorial.TokenService.CommonService();
common.Credentials = new NetworkCredential("AccountID", "password");
TokenSpecification tokenSpec = new TokenSpecification();
//Adresse IP de la machine du client
tokenSpec.ClientIPAddress = ipadr;
//Durée de validité du token (entre 15 et 480 minutes)
tokenSpec.TokenValidityDurationMinutes = 20;  

//Appel au Web Service Common pour récupération du token
string token = common.GetClientToken(tokenSpec);

On commence par récupérer l’adresse IP locale visible de l’extérieur. Cette adresse nous sera nécessaire pour la partie d’authentification (cette étape est inutile pour les applications Web).

On instancie ensuite la classe proxy CommonService puis on lui fournit le couple login/password récupéré sur la plateforme développeur. Cela se fait grâce à la propriété Credential de CommonService. On crée un NetworkCredential auquel on passe les informations nécessaires et on attribut ce NetworkCredential à la propriété Credential de CommonService.

La récupération d’un token se réalise grâce à la méthode GetClientToken (existe en version synchrone et asynchrone) à laquelle on passe un objet TokenSpecification.

Le TokenSpécification contient :

  • Propriété TokenValidityDurationMinutes: Le temps de validité du token en minutes (entre 15 et 480 minutes)
  • Propriété ClientIPAddress : L’adresse IP du client (inutile pour une application Web).

GetClientToken renvoie une chaine de caractères contenant le token.

  • Appel à une méthode Géocoding

Afin de vérifier que tout est bien configurer, on va demander les coordonnées géographiques de la ville de Paris.

GeocodeServiceClient geoCodeSvc = new GeocodeServiceClient();
GeocodeRequest geoCodeRequest = new GeocodeRequest();
geoCodeRequest.Credentials = new Credentials();
geoCodeRequest.Credentials.Token = token;
geoCodeRequest.Query = "Paris";
var result = geoCodeSvc.Geocode(geoCodeRequest);

On instancie un proxy pour GeocodeService. On crée un objet GeocodeServiceClient contenant une méthode GeoCode qui prend un paramètre un GeocodeRequest contenant les informations nécessaires à la requête. En général, les paramètres de requêtes des Web Services Virtual Earth demandent le token d’authentification dans la propriété Credential.Token. Afin de faire la recherche la plus simple possible, on fournit une chaine de caractères contenant “Paris” à la propriété Query. (nous reviendrons sur les requêtes plus complexe de Géocoding dans un autre post).

On obtient un GeoCodeResponse en retour qui nous fournit un certain nombre d’informations dont la localisation exacte de la ville de Paris.

Dans un prochain post, nous verrons plus en détail le Géocoding (et Géocoding Inverse) ainsi que les requêtes basiques au Web Service d’imagerie satellite.

11/03/2009

Erreur 404 lors d’un Debug d’un projet ASP.NET en utilisant “ASP.NET Development Server” sur localhost pour Vista

Classé dans : Hors Catégorie, Intermediaire — Mots-clefs :, , , , , , , , , — sebastiencourtois @ 12:10

Bon, le titre est un peu long pour un post aussi court mais il s’agit des mots clés que j’ai mis dans Google pour résoudre un bug qui m’empêchait de bosser depuis quelques temps (d’où le peu de post sur ce site récemment).

Lorsque je travaillais sur un projet ASP.NET (Silverlight ou autres), je me prenais systématiquement une page d’erreur 404 au lancement du débogage. J’étais sûr à 99.99 % que cela ne venait pas de mes projets car je les utilisait depuis plusieurs mois sans problème.

Après de longues recherches (car très peu de posts parlent de ce problème), j’ai trouvé le blog de Accidental Technologist et sur celui de Information for Technology qui indiquent que cela vient d’un bug/problème sous Vista avec les adresses IPv6 pour localhost.

La Solution :

Modifier le fichier hosts dans le répertoire C:\Windows\System32\drivers\etc.

Remplacer

::1             localhost

par

:::1             localhost  (si vous êtes en IPv6)

127.0.0.1             localhost  (si vous êtes en IPv4)

 

Cette solution m’a permis de visualiser ma page sous IE.

L’explication :

Je n’ai pas trouvé d’explication exacte quant à ce problème mais je vais vous donner ma reflexion :

en IPv4, l’adresse localhost est 127.0.0.1.

Avec l’arrivée de l’IPv6, on obtient l’adresse localhost suivante : 0:0:0:0:0:0:0:1

Or d’après la norme IpV6, on peut supprimer les 0 quand il y en a : 0:0:0:0:0:0:0:1 => :::::::1  (7 caractères ‘:’ et un caractère ‘1’)

Toujours d’après cette norme. Si plusieurs ‘:’ se suivent, on peut les remplacer par un seul au début et un seul à la fin donc  :::::::1 => ::1

Lorsque l’on tape dans IE, la chaine suivante : http://[::1]/ .On retombe bien sur la page localhost.

Deux questions me viennent donc à l’esprit :

1°) Pourquoi rajouter un ‘:’ dans le fichier host (Sachant que d’après la norme :  ::1 == :::1 == 0:0:0:0:0:0:0:1 et que ::1 est bien localhost dans la norme) ?

2°) Que s’est-il passé sur mon ordinateur pour que ce problème apparaisse alors que mes projets fonctionnaient correctement à l’origine (Problème détecté la première fois le 10/03/09) ?

Si vous arrivez à répondre à l’une de ces questions, n’hésitez pas à poster en commentaire :) . Je continue à chercher de mon coté et je mettrais à jour ce post si je trouve.

EDIT 11/03/09 12h27 : Apparemment pas le seul dans ce cas, car j’ai reçu ce mail  il y a quelques minutes (venant un Microsoft Student Partner dont je vais taire le nom :) ) :  “je voulais savoir si tu avais déjà eu des problèmes avec Cassini, parce que là il ne veut plus m’afficher aucune page que ce soit sur un site ASP.Net MVC, ou ASP.Net classique.”.

EDIT 11/03/09 15h00 : Il semble qu’une mise à jour de Windows Defender aurait modifier le fichier hosts entrainant des bugs sur les sites ‘localhost’

05/03/2009

Ajouter des fonctionnalités à des classes du Framework .NET (ou des classes .NET dont vous n’avez pas le code source)

Classé dans : .NET, Débutant — Mots-clefs :, , , , , — sebastiencourtois @ 16:59

Au cours de projet, vous pouvez être amené à avoir besoin d’ajouter des fonctionnalités à une classe du Framework .NET. Lorsque vous n’avez pas le code source de la classe en question, .NET vous propose trois manières simples d’étendre les fonctionnalités d’une classe.

La méthode passe partout : L’héritage

L’héritage est la méthode classique. Utilisable dans tous les langages objet, ce principe permet de redéfinir une classe en créant une autre classe plus spécifique reprenant les fonctionnalités de la classe générale.

En C#, cela se fait en utilisant le caractère ‘:’.

public class A {}
public class C : A {}

Dans l’exemple ci-dessus, la classe C dérive de A. Ainsi toute ce qui est défini en public ou protected dans A sera utilisable dans C. En plus, C pourra définir de nouvelles propriétés/méthodes.

Même si l’héritage reste le meilleur moyen pour ajouter des fonctionnalités, il y a un cas (au moins) dans lesquels on ne peut pas l’utiliser :

  • La classe mère est scellé (mot clé sealed). Impossible de faire de l’héritage.

Dans ce cas, le Framework .NET 2.0 nous fourni une solution : La partialité.

La méthode .NET 2.0 : Partialité

Le principe de la partialité est de reprendre une classe en ajoutant, dans un autre fichier source, des propriétés et des méthodes à la classe.

Pour cela on utilise le mot clé partial.

(Remarque : les classes partielles doivent être dans le même namespace)

Fichier A.cs : public sealed class A {}

Fichier A2.cs : public partial class A {}

La partialité n’étant pas de l’héritage, vous n’avez pas de problème avec le mot clé sealed. L’avantage de cette méthode est que votre code source référencera toujours la classe A quelque soit le nombre de fonctionnalités que vous aurez ajoutées  (avec l’héritage, vous auriez du remplacer toutes les occurrences de la classe A par B).

La partialité est notamment très utilisé dans Visual Studio pour les Winforms / WPF (séparation du code métier/ code interface).

La méthode .NET 3.5 : Les méthodes d’extensions

Cette dernière méthode a été introduite avec le Framework .NET 3.5. Le principe est de créer des méthodes pour une classe qui vont s’ajouter à celle-ci. Ces nouvelles méthodes seront placées dans une classe utilitaire statique (namespace/nom de classe différents de la classe visée). Le choix de la classe à étendre se fera dans le premier paramètres de la méthode précédé du mot clé this. Les méthodes d’extensions sont toujours statiques.

Blog4-1 On peut ensuite l’utiliser de façon très simple :

Blog4-2 Vous pouvez noter que l’IntelliSense fournit un icône particulier pour les méthodes d’extensions. De plus, vous pouvez voir le commentaire (extension) dans le Tooltip.

Les méthodes d’extensions sont une des bases de LINQ.

Articles plus anciens »

Publié sur WordPress.