Le portail francophone de la géomatique

Kevin Jousseaume · Sat 02 February 2013 09:09

Bonjour,

Nous avons développé pour le Grand Dijon un traitement ArcToolbox permettant de calculer, pour tout type de classe d'entités (point, ligne, polygone), l'URL affichant Google Map et Street View centrés sur chaque entité de la classe d'entités.

Par exemple, le point adresse du bâtiment abritant le Grand Dijon aura l'URL suivante : https://maps.google.com/maps?z=14&t … 11,0,0,0,0

Cet outil pouvant intéresser d'autres personnes, nous avons décidé, en accord avec le Grand Dijon, de le partager. Vous trouverez cet outil ainsi qu'une aide à son utilisation en pièce jointe.

Cordialement,
Kevin

[EDIT] : j'ai préféré supprimer le fichier joint qui ne correspondait plus à la dernière version de l'outil. Vous trouverez celle-ci à cette adresse : http://www.arcgis.com/home/item.html?id … 529e558008

Dernière modification par Kevin Jousseaume (Tue 19 February 2013 21:00)

Robin · Mon 04 February 2013 09:16

Bonjour Kevin

Merci tout d'abord pour ce partage. Pour être sûr qu'il ait un maximum de diffusion, peut être serait il intéressant de l'uploader sur le site d'ESRI en bonus ? Je n'ai jamais pratiqué dans ce sens , mais peut-être ici : http://resources.arcgis.com/content/upl … gis-online ?

Bonne semaine,
Robin.

Kevin Jousseaume · Mon 04 February 2013 09:42

Bonjour Robin,

Merci pour cette suggestion, j'essaierai de le faire prochainement .

Bonne semaine également,
Kevin.

Kevin Jousseaume · Sun 17 February 2013 16:17

Suite aux (toujours) judicieux conseils de Robin, j'ai mis en partage cet outil sur ArcGIS Online à cette adresse : http://www.arcgis.com/home/item.html?id … 529e558008

J'en ai profité pour apporter une amélioration. L'outil passe par une étape intermédiaire de reprojection en WGS84. Dans la précédente version, cela ne fonctionnait correctement qu'avec les données en RGF93, les paramètres de la reprojection (système de coordonnées de la couche + transformation géographique à utiliser) étant en "dur" dans le script. Désormais, ces paramètres sont externalisés et doivent être renseignés au lancement de l'outil. Cependant, le système de coordonnées est automatiquement renseigné et, pour les données dans les systèmes RGF93 ou Lambert Zone, la transformation la plus adaptée est également pré-remplie (mais elle peut être modifiée si désiré).

Cordialement,
Kevin

[Edit : merci Robin pour la remarque, j'ai modifié le lien en conséquence !]

Dernière modification par Kevin Jousseaume (Mon 18 February 2013 10:43)

Robin · Mon 18 February 2013 09:46

Bonjour Kevin et merci,

Par contre, il y a un truc qui cloche, le lien pointe vers un autre outil : " Sélection vers ensemble de définition".

EDIT Robin : ca marche à présent

Nicolas Granier · Tue 19 February 2013 08:55

Bonjour,
et merci pour cet outil !

Je viens de le tester à l'instant et je me permets d'apporter une observation mineure.
L'outil ne fonctionne que lorsque la couche est en géodatabase.
En shape une erreur remonte sur le nom du champ par exemple :

Code:

le champ macouche.shp.google n'existe pas

Il n'y a pas grand chose à faire pour le faire fonctionner en shape, il suffirait juste de teste le retour du "desc.name" pour faire un test et faire sauter le ".shp" récalcitrant.

Sinon en fgdb c'est parfait !
Merci encore

Nicolas GRANIER

Robin · Tue 19 February 2013 09:40

Même souci sur le .shp (je suis sur la 10.1)

Sinon, j'aime beaucoup le retour vers l'utilisateur, c'est rare qu'un code explique les étapes qu'il suit aussi précisément. En général, ça fait plutôt boite noire. J'avais déjà remarqué ça sur ton précédent script pour inverser les polylignes.

Kevin Jousseaume · Tue 19 February 2013 10:54

Bonjour,

Merci pour ces retours, j'apporterai la correction dès que possible !

Et merci pour les compliments

Bien à vous,
Kevin.

pchevallot · Tue 19 February 2013 17:55

Bonjour Kévin,

Merci beaucoup et bravo pour cet outil, auquel je vais trouver rapidement des usages très utiles.

Pascal

Kevin Jousseaume · Tue 19 February 2013 21:02

Nicolas a écrit :
Il n'y a pas grand chose à faire pour le faire fonctionner en shape, il suffirait juste de teste le retour du "desc.name" pour faire un test et faire sauter le ".shp" récalcitrant.

Voilà, c'est fait

Dernière modification par Kevin Jousseaume (Tue 19 February 2013 21:03)

Robin · Wed 20 February 2013 09:36

Ca fonctionne impecc sur la 10.1, merci.

Si jamais quelqu'un(*) veut améliorer le script (mais c'est du luxe) :
1. Restreindre les coordonnées à 6 décimales max (visiblement google ne va plus loin) pour réduire la taille du champ.
2. Vérifier que le champ URL que l'on choisit comporte suffisamment de caractères (champs chaine 150 caractères au moins) pour éviter les url tronquées.
3. Mettre dans l'aide du zoom une équivalence entre niveau de zoom (de 0 à 20) et emprise équivalente . Z= 0 -> monde, Z = 5 -> Europe, Z = 6 -> France, Z = 9 > département, Z = 15 -> ville, Z = 20 -> zone de 1ha environ

* Pas de raison que Kevin soit seul à bosser, hein

Lebon henry · Wed 20 February 2013 10:40

Bonjour,

En premier lieu merci pour ce script. Ensuite, je voudrais savoir s'il est possible d'intégrer un azimut à l'url google ?

cordialement.

Kevin Jousseaume · Wed 20 February 2013 12:17

Merci Robin pour toutes ces excellentes suggestions !!! Je laisse quelques jours aux amateurs qui souhaiteraient apporter ces améliorations à l'outil, sinon je me pencherai dessus ce week-end.

Ensuite, je voudrais savoir s'il est possible d'intégrer un azimut à l'url google ?

Vous trouverez des informations très intéressantes sur le paramétrage de l'URL : http://stackoverflow.com/questions/3879 … l-question
Ainsi, la seconde valeur du paramètre cbp correspond à l'azimut. Reste à savoir comment vous souhaitez renseigner ce paramètre : à partir d'un champ existant (simple), à partir de calculs sur l'orientation des entités (complexe et non adapté pour des ponctuels) ?

Nicolas Granier · Thu 21 February 2013 08:22

Bonjour,

J'ai testé l'outil sur un grand jeu de données 25 000 objets linéaires et comme indiqué par Kévin, le traitement peu être long.

Si le traitement s'applique sur de nombreuses entités, il prendra plusieurs dizaines de minutes. Privilégiez tant que faire se peut des lots d'entités inférieurs à 100 000 enregistrements.

Je propose une modification pour optimiser les temps de traitement.
J'ai identifié d'où venait le traitement le plus long et c'est sans surprise le dernier calcul dans la table attributaire faisant appel à une jointure attributaire.

Code:

Ci dessous un extrait des temps de traitement
Exécution du script GoogleMapURL...
2013/02/20-13:04:46 - Espace de travail temporaire : C:\Users\ON-X\Documents\ArcGIS\Default.gdb
2013/02/20-13:04:49 - Copie temporaire des entités sélectionnées...
2013/02/20-13:04:54 - Comparaison du système de coordonnées en entrée avec le WGS84...
2013/02/20-13:04:54 - Reprojection des entités...
2013/02/20-13:05:05 - Calcul du champ Longitude...
2013/02/20-13:05:16 - Calcul du champ Latitude...
2013/02/20-13:05:28 - Ajout de la jointure...
2013/02/20-13:05:29 - Calcul du champ GOOGLE...

L'éxecution des premières commandes prend de 1 ou 2 minutes mais le dernier calcul dans mon cas prend une paire d'heure.
Le vrai ralentissement n'est pas le calcul du champ en lui même mais la jointure.
Après avoir fait quelques tests, je me propose l'optimisation suivante.

- faire le calcul de l'URL GOOGLE directement dans la table temporaire

Code:

#ajout du champ GOOGLE
fldName_GOO = "GOO"
arcpy.AddField_management(TMP_FC_PROJECT, fldName_GOO, "TEXT", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")

- calcul du champ GOOGLE

Code:

arcpy.CalculateField_management(TMP_FC_PROJECT, fldName_GOO, "\"http://maps.google.com/maps?z="+ INPUT_LEVEL +"&t=m&q=\" + str(!"+fldName_LAT +"!).replace(\",\",\".\") + \",\" + str(!"+ fldName_LON +"!).replace(\",\",\".\") + \"&cbll=\" + str(!"+fldName_LAT +"!).replace(\",\",\".\") + \",\" + str(!"+ fldName_LON +"!).replace(\",\",\".\") + \"&layer=c&cbp=11,0,0,0,0\"", "PYTHON", "")

- et rappatriement de ce champ en utilisant cette méthode de jointure

Code:

arcpy.JoinField_management (INPUT_FLAYER, OIDFieldName, TMP_FC_PROJECT, TMP_FLD_PK,[fldName_GOO])

La méthode JoinField_management présente l'avantage de pouvoir rappatrier un champ dans une autre table en faisant un lien sur les ID. Même principe en théorie que la méthode AddJoin_management sauf qu'en pratique il ne s'agit pas d'une réelle jointure car une fois la table temporaire supprimée, le champ join existe toujours bel et bien dans la table finale. J'en fais peut être une utilisation dérivée mais dans mon cas, j'économise du temps, l'exécution passe de 2H à 2 minutes.

Code:

Exécution du script GoogleMapURL...
2013/02/20-16:14:59 - Espace de travail temporaire : C:\Users\ON-X\Documents\ArcGIS\Default.gdb
2013/02/20-16:14:59 - Copie temporaire des entités sélectionnées...
2013/02/20-16:15:03 - Comparaison du système de coordonnées en entrée avec le WGS84...
2013/02/20-16:15:03 - Reprojection des entités...
2013/02/20-16:15:10 - Calcul du champ Longitude...
2013/02/20-16:15:22 - Calcul du champ Latitude...
2013/02/20-16:15:33 - Calcul du champ GOOGLE dans la table temporaire...
2013/02/20-16:15:38 - Rappatriement du champ de la table temporaire vers la table finale
2013/02/20-16:16:40 - Suppression des données temporaires...
2013/02/20-16:16:41 - FIN DES TRAITEMENTS
Completed script GoogleMapURL...
réussie à Wed Feb 20 16:16:41 2013 (temps écoulé : 1 minutes 42 secondes)

Bien sur il faut ensuite adapter le formulaire utilisateur car il ne faut pas avoir préalablement avoir créé le champ Google car celui-ci sera créé dans la table temporaire.

Je pense que cette optimisation serait utile, après je n'oblige à rien.
J'ai mis les lignes de codes et le principe de fonctionnement dans ce post, si besoin je fournis le .py.

A+
Nicolas GRANIER

Dernière modification par Nicolas Granier (Thu 21 February 2013 08:24)

Lebon henry · Thu 21 February 2013 09:32

Kevin Jousseaume a écrit:

Vous trouverez des informations très intéressantes sur le paramétrage de l'URL : http://stackoverflow.com/questions/3879 … l-question
Ainsi, la seconde valeur du paramètre cbp correspond à l'azimut. Reste à savoir comment vous souhaitez renseigner ce paramètre : à partir d'un champ existant (simple), à partir de calculs sur l'orientation des entités (complexe et non adapté pour des ponctuels) ?

Merci bien, j'ai pu intégrer l'azimut présent dans un champ de la table attributaire en modifiant la concaténation dans le champ google.

Kevin Jousseaume · Thu 21 February 2013 14:08

Merci infiniment Nicolas pour cette solution très "sioux" permettant de réduire de manière si significative les temps de réponse !!!

A dire vrai, je n'ai pas pris le temps pour l'instant de me pencher sur ce sujet de performance. Je m'étais dit que je testerais une autre méthode que le CalculateField_management : ouvrir un curseur de mise à jour, parcourir toutes les entités issues de la jointure, puis pour chacune calculer le champ GOOGLE.

J'essaierai de prendre le temps de tester cette alternative dans le jours qui viennent. Si elle n'améliore pas les temps de réponse, je vous propose de compléter la boite à outils avec un nouvel outil de création du champ reprenant votre méthode. L'utilisateur aura alors le choix entre:
1. créer le champ de toute pièce (il devra alors disposer des droits de modification de la structure de la classe d'entités ; permet de créer un champ de toute pièce respectant la longueur minimale)
2. mettre à jour le champ existant (permet de ne pas à avoir à modifier la structure de la classe d'entités).

Dans tous les cas, je vous citerai bien sur en tant que contributeurs de l'outil

Lebon henry a écrit :
Merci bien, j'ai pu intégrer l'azimut présent dans un champ de la table attributaire en modifiant la concaténation dans le champ google.

Tant mieux !

Dernière modification par Kevin Jousseaume (Thu 21 February 2013 14:09)

Kevin Jousseaume · Fri 22 February 2013 08:23

Nicolas GRANIER a écrit:
Je pense que cette optimisation serait utile, après je n'oblige à rien.

Après avoir bataillé en tentant de mettre à jour les données d'une table jointe, j'ai finalement trouvé LA solution : ne pas utiliser de jointure du tout... Avec cette méthode, la mise à jour de 53610 enregistrements dans une geodatabase fichier prend 23s

N'étant pas un vrai développeur (je sais, les apparences sont trompeuses ), j'ai eu la chance de tomber sur ce post : http://forums.arcgis.com/threads/55099- … ctionaries

Le principe : construire en mémoire, en parcourant la classe d'entités temporaire reprojetée, un dictionnaire avec l'identifiant unique (champ TMP_FLD_PK dans mon code) comme clef et un tableau avec les longitudes/latitudes en valeur.

Code:

    dictValues = {}
    fieldList = [fldName_LON,fldName_LAT]
    rows = arcpy.SearchCursor(TMP_FC_PROJECT)
    
    for row in rows:
      dictFieldValues = {}
      for field in fieldList:    
        dictFieldValues[field] = str(round(row.getValue(field),6))

      dictValues[row.getValue(TMP_FLD_PK)] = dictFieldValues

    del row, rows

Puis ouvrir un curseur de mise à jour sur la classe d'entités en entrée et, pour chaque entité, récupérer l'identifiant (le champ OID dans notre cas) et à partir de cet identifiant les informations de longitude/latitude associées dans le dictionnaire. Puis construire l'URL avec tout ça et l'affecter au champ GOOGLE.

Code:

    rowsUpdate = arcpy.UpdateCursor(INPUT_FLAYER)
    
    for rowUpdate in rowsUpdate:
      oid = rowUpdate.getValue(OIDFieldName)
      sLon = dictValues[oid][fldName_LON]
      sLat = dictValues[oid][fldName_LAT]
  
      sUrl =  "http://maps.google.com/maps?z="+ INPUT_LEVEL +"&t=m&q=" + sLat + "," + sLon + "&cbll=" + sLat + "," + sLon + "&layer=c&cbp=11,0,0,0,0"

      rowUpdate.setValue(INPUT_FLD_GOOGLE, sUrl)
      rowsUpdate.updateRow(rowUpdate)
        
    del rowsUpdate, rowUpdate

Cette solution ne présente qu'une seule contrainte : l'outil doit nécessairement être exécuté au premier plan (c'est une option dans l'onglet Général des propriétés de l'outil), sinon l'ouverture du curseur de mise à jour ne peut pas se faire (impossible d'obtenir un verrou sur la classe d'entités). Mais bon, vu le temps d'exécution obtenu, cela me parait un bien moindre mal !

Je vous ferai un joli package ce week-end intégrant les petites améliorations suggérées par Robin.

Bonne journée,
Kevin

Kevin Jousseaume · Sat 23 February 2013 18:49

Bonjour,

Une nouvelle version vous attend. Voici les principales évolutions :
1. modification de la méthode de calcul des coordonnées. Remplacement du CalculateField par une boucle avec un UpdateCursor => permet de gagner 50% du temps de calcul des coordonnées. Et pour Robin, j'ai arrondi au 6ème chiffre significatif
2. modification de la méthode de calcul du champ Google. Remplacement de la jointure et du CalculateField par une boucle avec un UpdateCursor => permet désormais d'exécuter les traitements sur un lot conséquent de données.
3. ajout du paramètre optionnel de l'azimut => Henry, tu pourras donc bénéficier des améliorations apportées tout en conservant tes azimuts
4. ajout du paramètre sur le choix de la syntaxe href => SIG03, si tu passes par là, celle-ci t'est dédicacée...
5. contrôle de la longueur du champ Google : si elle est insuffisante, on arrête le traitement. J'ai essayé d'ajouter un contrôle (avec un message d'erreur si le champ choisi fait moins de x caractères) directement dans la classe de validation (ToolValidator) de l'outil (dans la méthode updateMessages), mais sans succès. Si quelqu'un a envie de se pencher dessus, qu'il n'hésite pas !
6. contrôle de la validité de la géométrie de l'objet. Un message d'avertissement prévient l'utilisateur que l'objet d'OID xxx possède une géométrie invalide, mais le traitement se poursuit malgré tout pour les autres entités => en refaisant des tests sur des classes d'entités volumineuses, je suis tombé sur des objets qui n'avaient pas de géométrie. Avec la méthode précédente CalculateField, il n'y avait pas d'erreur mais l'URL générée était invalide (NaN en lieu et place des coordonnées). Maintenant on sait qu'il y a un problème, sans pour autant empêcher le renseignement des entités valides.
7. j'ai complété l'aide qui était inexistante en m'inspirant fortement des remarques de Robin.

J'espère que cette version vous plaira .

Bonne fin de week-end,
Kevin.

dominique.lys · Sun 24 February 2013 19:04

Bonjour,

Je n'ai pas regardé le code dans le détail mais visiblement tu reprojettes la couche en WGS84 or il est possible d'obtenir directement les coordonnées dans ce système.

Voici un extrait d'un script (en 9.3) pour lequel je calcul un champs avec les url vers le geoportail français:

Code:

srOut = gp.CreateObject("SpatialReference")
srOut.CreateFromFile("C:\\Program Files\\ArcGIS\\Coordinate Systems\\Geographic Coordinate Systems\\World\\WGS 1984.prj")
# Create cursor. Use WGS84 spatial reference object so geometries are returned in decimal degrees.
cur = gp.UpdateCursor(inLay, "", srOut)
row = cur.Next()
i=1
while row:
    centroid=row.shape.centroid
    x,y=centroid.x, centroid.y
    row.xgps=x
    row.ygps=y
    row.num=i
    #row.hyperlien="http://www.geoportail.fr/?c=" + str(x) + "," + str(y) + "&z=4&l=Photo"
    row.hyperlien="http://www.geoportail.gouv.fr/accueil?c=" + str(x) + "," + str(y) + "&z=0.000021&l=ORTHOIMAGERY.ORTHOPHOTOS$GEOPORTAIL:OGC:WMTS(1)&permalink=yes"
    cur.UpdateRow(row)
    row = cur.Next()
    i+=1
del row,cur # must close to flush file buffers

L'astuce est de spécifier un système de coordonnée pour le curseur afin d'obtenir à la volée les coordonnées des géométries dans ce système.
D'ailleurs on peut faire ça dans Acmap, il suffit de définir le système de coordonnée du data frame en WGS84 ensuite lorsqu'on lance "calculate geometry" sur un champs on peut choisir soit la projection de la source donnée soit la projection du data frame.

Peut être cela peut t'éviter les jointures et simplifier le code.

A+

Dernière modification par dominique.lys (Sun 24 February 2013 19:19)

Kevin Jousseaume · Sun 24 February 2013 21:27

Merci Dominique, je testerai ça très vite !!!

Et puis j'en profiterai pour proposer les 2 URLs : GoogleMap et geoportail

A+,
Kevin.

Kevin Jousseaume · Mon 25 February 2013 08:04

J'ai testé, c'est effectivement bien plus efficace !!! Sur mon ordi, pour des données au format geodatabase fichier, cela va ainsi 3 fois plus vite (et puis ça évite d'être confronté au risque de manque d'espace disque lors de la reprojection physique des données).

J'ai juste un petit bémol à émettre avec cette solution : la reprojection dans le curseur ne permet pas d'appliquer la méthode de transformation, ce qui induit un risque de décalage du résultat plus ou moins important en fonction du système de coordonnées en entrée. Je suppose que c'est une des raisons pour lesquelles dans la v10.1 l'objet Geometry dispose désormais d'une méthode projectAs(spatial_reference, {transformation_name}) qui offre la possibilité d'inclure une méthode de transformation.

J'ai ainsi testé rapidement :
- avec un jeu de données en NTF_Lambert_II_étendu, j'obtiens un écart de 5m.
- aucun écart avec des données en RGF_1993_Lambert_Zone_6
Il faudrait que je me plonge dans les méthodes de transformation d'ArcGIS pour en savoir plus, mais je n'en ai guère le courage

Quoiqu'il en soit, je te remercie encore Dominique pour cette solution que j'ai incluse dans l'outil (mais je n'ai pas encore postée cette version) en ajoutant une option dans l'interface. Je vais également tester dans les prochains jours l'ajout d'une fonction dédiée à la v10.1. Le script détectera la version d'ArcGIS et exécutera la fonction adaptée. J'essaierai d'en faire de même pour la v9.3, mais cela me sera plus difficile de tester.

En vous souhaitant un bon début de semaine.
Kevin

Kevin Jousseaume · Mon 25 February 2013 08:14

Ah, et pour l'URL du geoportail, je pense faire un deuxième outil car les paramètres ne sont pas les mêmes. Le niveau d'échelle est différent et surtout il est possible de choisir de superposer plusieurs fond de plan avec une certaine transparence.

Par défaut, je commencerai probablement par afficher l'orthophoto et le réseau routier comme ceci :
http://www.geoportail.gouv.fr/accueil?c … malink=yes

Si vous avez des suggestions, je suis preneur !

Kevin Jousseaume · Mon 25 February 2013 20:47

Bonsoir,

Voilà, j'ai posté une nouvelle version. Les modifications apportées sont les suivantes :
1. amélioration de l'outil pour qu'il utilise le module Data Access dans le cas où ArcGIS Desktop est en version 10.1
2. ajout d'une option de reprojection "à la volée" sans utilisation de méthode de transformation. Cette option est 2 à 3 fois plus rapide mais peut induire un décalage de plusieurs dizaines de mètres en fonction du système de coordonnées en entrée.

Sous ArcGIS 10.1, j'ai essayé d'utiliser la méthode projectAs de l'objet Geometry mais sans succès. J'ai donc bien opté pour le choix de la méthode : avec ou sans transformation pour optimiser les calculs (au détriment parfois, mais pas systématiquement, de la précision).

A bientôt,
Kevin

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Annonce

#1 Sat 02 February 2013 09:09

[ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#2 Mon 04 February 2013 09:16

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#3 Mon 04 February 2013 09:42

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#4 Sun 17 February 2013 16:17

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#5 Mon 18 February 2013 09:46

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#6 Tue 19 February 2013 08:55

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

Code:

#7 Tue 19 February 2013 09:40

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#8 Tue 19 February 2013 10:54

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#9 Tue 19 February 2013 17:55

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#10 Tue 19 February 2013 21:02

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#11 Wed 20 February 2013 09:36

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#12 Wed 20 February 2013 10:40

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#13 Wed 20 February 2013 12:17

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#14 Thu 21 February 2013 08:22

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

Code:

Code:

Code:

Code:

Code:

#15 Thu 21 February 2013 09:32

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#16 Thu 21 February 2013 14:08

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#17 Fri 22 February 2013 08:23

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

Code:

Code:

#18 Sat 23 February 2013 18:49

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#19 Sun 24 February 2013 19:04

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

Code:

#20 Sun 24 February 2013 21:27

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#21 Mon 25 February 2013 08:04

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#22 Mon 25 February 2013 08:14

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

#23 Mon 25 February 2013 20:47

Re: [ArcGIS 10] : outil de calcul de l'URL Google Map et Street View

Pied de page des forums