Search

Operations

Get Search Address

Géocodage des adresses

S’applique à: niveaux tarifaires S0 et S1.

Dans de nombreux cas, le service de recherche complet peut être trop grand, par exemple si vous êtes uniquement intéressé par le géocodage traditionnel. Vous pouvez également accéder à la recherche pour rechercher des adresses exclusivement. Le géocodage est effectué en atteignant le point de terminaison géocode avec uniquement l’adresse ou l’adresse partielle en question. L’index de recherche géocodage sera interrogé pour tout ce qui se trouve au-dessus des données au niveau de la rue. Aucun POI n’est retourné. Notez que le géocodeur est très tolérant aux fautes de frappe et aux adresses incomplètes. Il gérera également tous les éléments, qu’il s’agisse de la rue ou de l’adresse, ainsi que des zones géographiques de niveau supérieur, telles que les centres de ville, les comtés, les États, etc.

Get Search Address Reverse

Inverser le géocode d’une adresse

S’applique à: niveaux tarifaires S0 et S1.

Il peut arriver que vous deviez traduire une coordonnée (exemple : 37,786505,-122,3862) en adresse postale compréhensible par l’utilisateur. Le plus souvent, cela est nécessaire dans les applications de suivi où vous recevez un flux GPS de l’appareil ou de la ressource, et que vous souhaitez connaître l’adresse où se trouve la coordonnée. Ce point de terminaison retourne des informations d’adresse pour une coordonnée donnée.

Get Search Address Reverse Cross Street

Inverser le géocode vers une rue croisée

S’applique à: niveaux tarifaires S0 et S1.

Il peut arriver que vous deviez traduire une coordonnée (exemple : 37,786505,-122,3862) en une croix compréhensible par l’homme. Le plus souvent, cela est nécessaire dans les applications de suivi où vous recevez un flux GPS de l’appareil ou de la ressource, et que vous souhaitez connaître l’adresse où se trouve la coordonnée. Ce point de terminaison renverra des informations sur les rues pour une coordonnée donnée.

Get Search Address Structured

Géocodage d’adresses structurées

S’applique à: niveaux tarifaires S0 et S1.

Le géocodage d’adresse Azure est également accessible pour la recherche d’adresses structurées exclusivement. L’index de recherche géocodage sera interrogé pour tout ce qui se trouve au-dessus des données au niveau de la rue. Aucun POI n’est retourné. Notez que le géocodeur est très tolérant aux fautes de frappe et aux adresses incomplètes. Il gérera également tous les éléments, qu’il s’agisse de la rue ou de l’adresse, ainsi que des zones géographiques de niveau supérieur, telles que les centres de ville, les comtés, les États, etc.

Get Search Fuzzy

Recherche de forme libre

S’applique à: niveaux tarifaires S0 et S1.

L’API par défaut de base est une recherche de formulaire libre qui gère le plus grand nombre d’entrées qui gère une combinaison de jetons d’adresse ou d’adresse. Cette API de recherche est la « recherche sur une seule ligne » canonique. L’API de recherche de forme libre est une combinaison transparente de recherche et de géocodage. L’API peut également être affinée avec une position contextuelle (paire lat./lon.), paire), ou entièrement contraint par une coordonnée et un rayon, ou elle peut être exécutée plus généralement sans point d’ancrage géo-biais.

Nous vous conseillons vivement d’utiliser le paramètre « countrySet » pour spécifier uniquement les pays dont votre application a besoin, car le comportement par défaut consiste à rechercher dans le monde entier, ce qui risque de renvoyer des résultats inutiles.

Par exemple : countrySet = US, fr

Pour obtenir la liste complète de tous les pays pris en charge, consultez la couverture de recherche .

La plupart des requêtes de recherche ont par défaut la valeur maxFuzzyLevel = 2 pour obtenir des performances et réduire également les résultats inhabituels. Cette nouvelle valeur par défaut peut être remplacée en fonction des besoins par demande en transmettant le paramètre de requête maxFuzzyLevel = 3 ou 4.

Get Search Nearby

Recherche proche

S’applique à: niveaux tarifaires S0 et S1.

Si vous avez un cas d’usage pour récupérer uniquement les résultats de la recherche d’un emplacement spécifique, la méthode de recherche de proximité peut être le bon choix. Ce point de terminaison renvoie uniquement les résultats de point d’intérêt et ne prend pas en compte un paramètre de requête de recherche.

Get Search POI

Obtient le nom de la

S’applique à: niveaux tarifaires S0 et S1.

La recherche de points d’intérêt (e) vous permet de demander des résultats de recherche à l’aide d’un nom. La recherche prend en charge des paramètres de requête supplémentaires tels que la langue et le filtrage des résultats par zone d’intérêt pilotée par pays ou cadre englobant. Le point de terminaison retourne uniquement les résultats de la chaîne de requête. La réponse comprend des détails sur les éléments tels que l’adresse, la position de la coordonnée et la catégorie.

Get Search POI Category

Accéder à l’aide de la catégorie

S’applique à: niveaux tarifaires S0 et S1.

La recherche de catégorie points d’intérêt (e) vous permet de demander des résultats de recherche à partir d’une catégorie donnée. La recherche permet à d’interroger POI à partir d’une catégorie à la fois. Le point de terminaison retourne uniquement les résultats de la catégorie par catégories spécifiés. La réponse comprend des détails sur les éléments tels que l’adresse, l’emplacement des coordonnées et la classification.

Get Search POI Category Tree Preview

Extraire l’arborescence des catégories

S’applique à: niveaux tarifaires S0 et S1.

L’API de la catégorie d’e-d fournit une liste complète des catégories et sous-catégories de points d’intérêt pris en charge, ainsi que leurs traductions et synonymes. Le contenu retourné peut être utilisé pour fournir des résultats plus significatifs par le biais d’autres API de Search Service, par exemple obtenir la recherched’un aller-retour.

Get Search Polygon

Obtient le polygone

S’applique à: niveau tarifaire S1.

Le service obtenir le polygone vous permet de demander les données géométriques telles qu’une structure de ville ou de pays pour un ensemble d’entités, précédemment Récupérée à partir d’une demande de recherche en ligne au format géojson. L’ID Geometry est retourné dans l’objet dataSources sous « Geometry » et « ID » dans une adresse de recherche ou un appel de recherche flou.

Notez que tous les ID de géométrie récupérés à partir d’un point de terminaison de recherche en ligne ont une durée de vie limitée. Le client ne doit pas stocker les ID de géométrie dans un stockage persistant pour une référence ultérieure, car la stabilité de ces identificateurs n’est pas garantie pendant une longue période de temps. Il est prévu qu’une demande à la méthode Polygon soit effectuée en quelques minutes de la requête à la méthode de recherche en ligne qui a fourni l’ID. Le service autorise les requêtes par lot jusqu’à 20 identificateurs.

Post Search Address Batch

API de traitement par lot de l’adresse de recherche

S’applique à: niveau tarifaire S1.

L’API de lot d’adresses de recherche envoie des lots de requêtes pour Rechercher l’API d’adresse à l’aide d’un simple appel d’API. Vous pouvez appeler l’API de lot d’adresses de recherche pour exécuter de façon asynchrone (asynchrone) ou synchrone (synchronisation). L’API Async permet à l’appelant de traiter jusqu’à 10 000 requêtes et l’API de synchronisation jusqu’à 100 requêtes.

Envoyer une demande de lot synchrone

L’API synchrone est recommandée pour les requêtes de lots légères. Lorsque le service reçoit une demande, il répond dès que les éléments du lot sont calculés et il n’est pas possible de récupérer les résultats ultérieurement. L’API synchrone renverra une erreur de délai d’attente (une réponse 408) si la demande prend plus de 60 secondes. Le nombre d’éléments de lot est limité à 100 pour cette API.

POST https://atlas.microsoft.com/search/address/batch/sync/json?api-version=1.0&subscription-key={subscription-key}

Envoyer une demande de lot asynchrone

L’API asynchrone est appropriée pour le traitement de grands volumes de requêtes de recherche relativement complexes

  • Il permet la récupération des résultats dans un appel séparé (plusieurs téléchargements sont possibles).
  • L’API asynchrone est optimisée pour la fiabilité et n’est pas censée être exécutée dans un délai d’attente.
  • Le nombre d’éléments de lot est limité à 10 000 pour cette API.

Lorsque vous effectuez une requête à l’aide de la requête Async, par défaut, le service retourne un code de réponse 202 le long d’une URL de redirection dans le champ d’emplacement de l’en-tête de réponse. Cette URL doit être vérifiée régulièrement jusqu’à ce que les données de réponse ou les informations d’erreur soient disponibles. Les réponses asynchrones sont stockées pendant 14 jours. L’URL de redirection renvoie une réponse 404 si elle est utilisée après la période d’expiration.

Notez que la demande de lot asynchrone est une demande longue. Voici une séquence typique d’opérations :

  1. le Client envoie une POST demande de lot d’adresses de recherche à Azure Maps

  2. Le serveur répondra avec l’un des éléments suivants :

    La 202 Accepted demande http-batch a été acceptée.

    HTTP Error -une erreur s’est produite lors du traitement de votre requête de lot. Il peut s’agir d’un 400 Bad Request ou de tout autre Error code d’État.

  3. Si la demande de lot a été acceptée avec succès, l' Location en-tête de la réponse contient l’URL permettant de télécharger les résultats de la requête de lot. Cet URI d’État ressemble à ce qui suit :

    GET https://atlas.microsoft.com/search/address/batch/{batch-id}?api-version=1.0&subscription-key={subscription-key}
  1. Le client émet une GET requête sur l' URL de téléchargement obtenue à l’étape 3 pour télécharger les résultats du lot.

Corps de publication pour la demande de lot

Pour envoyer les requêtes d' adresse de recherche , vous allez utiliser une POST requête dans laquelle le corps de la demande contient le batchItems tableau au json format et l' Content-Type en-tête est défini sur application/json . Voici un exemple de corps de demande contenant 5 requêtes d' adresse de recherche :

{
    "batchItems": [
        {"query": "?query=400 Broad St, Seattle, WA 98109&limit=3"},
        {"query": "?query=One, Microsoft Way, Redmond, WA 98052&limit=3"},
        {"query": "?query=350 5th Ave, New York, NY 10118&limit=1"},
        {"query": "?query=Pike Pl, Seattle, WA 98101&lat=47.610970&lon=-122.342469&radius=1000"},
        {"query": "?query=Champ de Mars, 5 Avenue Anatole France, 75007 Paris, France&limit=1"}
    ]
}

Une requête d' adresse de recherche dans un lot est simplement une URL partielle sans le protocole, l’URL de base, le chemin d’accès, la version d’API et la clé d’abonnement. Il peut accepter n’importe quel paramètre d’URId' adresse de recherche pris en charge. Les valeurs de chaîne dans la requête d' adresse de recherche doivent être correctement placées dans une séquence d’échappement (par exemple, «le caractère doit être placé dans une séquence d’échappement avec \ ) et être correctement encodé en URL.

L’API Async permet à l’appelant de traiter jusqu’à 10 000 requêtes et l’API de synchronisation jusqu’à 100 requêtes, et le lot doit contenir au moins 1 requête.

Télécharger les résultats asynchrones par lot

Pour télécharger les résultats de lot asynchrones, vous devez émettre une GET demande au point de terminaison de téléchargement par lot. Cette URL de téléchargement peut être obtenue à partir de l' Location en-tête d’une POST demande de lot réussie et se présente comme suit :

https://atlas.microsoft.com/search/address/batch/{batch-id}?api-version=1.0&subscription-key={subscription-key}

Voici la séquence classique des opérations de téléchargement des résultats du lot :

  1. Le client envoie une GET demande à l’aide de l' URL de téléchargement.

  2. Le serveur répondra avec l’un des éléments suivants :

    La 202 Accepted requête http-batch a été acceptée, mais elle est toujours en cours de traitement. Réessayez plus tard.

    HTTP 200 OK -demande de lots traitée avec succès. Le corps de la réponse contient tous les résultats de lot.

Modèle de réponse par lot

Le contenu des données retournées est similaire pour les demandes Async et Sync. Lors du téléchargement des résultats d’une demande de lot asynchrone, si le lot a terminé le traitement, le corps de la réponse contient la réponse du lot. Cette réponse par lot contient un summary composant qui indique le totalRequests qui fait partie de la requête de lot d’origine et, par exemple, les successfulRequests requêtes qui ont été exécutées avec succès. La réponse par lot inclut également un batchItems tableau qui contient une réponse pour chaque requête de la requête de lot. batchItemsContient les résultats dans l’ordre exact où les requêtes d’origine ont été envoyées dans la requête de lot. Chaque élément dans batchItems contient statusCode les response champs et. Chaque response dans batchItems est de l’un des types suivants :

  • SearchAddressResponse -Si la requête s’est terminée correctement.

  • Error -Si la requête a échoué. Dans ce cas, la réponse contient un code et un message .

Voici un exemple de réponse par lot avec 2 réussites et 1 résultat d' échec :

{
    "summary": {
        "successfulRequests": 2,
        "totalRequests": 3
    },
    "batchItems": [
        {
            "statusCode": 200,
            "response":
            {
                "summary": {
                    "query": "one microsoft way redmond wa 98052"
                },
                "results": [
                    {
                        "position": {
                            "lat": 47.63989,
                            "lon": -122.12509
                        }
                    }
                ]
            }
        },
        {
            "statusCode": 200,
            "response":
            {
                "summary": {
                    "query": "pike pl seattle wa 98101"
                },
                "results": [
                    {
                        "position": {
                            "lat": 47.60963,
                            "lon": -122.34215
                        }
                    }
                ]
            }
        },
        {
            "statusCode": 400,
            "response":
            {
                "error":
                {
                    "code": "400 BadRequest",
                    "message": "Bad request: one or more parameters were incorrectly specified or are mutually exclusive."
                }
            }
        }
    ]
}
Post Search Address Reverse Batch

Rechercher une adresse API de lot inverse

S’applique à: niveau tarifaire S1.

L’API de lot d’adresses de recherche envoie des lots de requêtes pour Rechercher l’API inverse de l’adresse à l’aide d’un simple appel d’API. Vous pouvez appeler l’API de traitement par lots de l’adresse de recherche pour exécuter de façon asynchrone (asynchrone) ou synchrone (synchronisation). L’API Async permet à l’appelant de traiter jusqu’à 10 000 requêtes et l’API de synchronisation jusqu’à 100 requêtes.

Envoyer une demande de lot synchrone

L’API synchrone est recommandée pour les requêtes de lots légères. Lorsque le service reçoit une demande, il répond dès que les éléments du lot sont calculés et il n’est pas possible de récupérer les résultats ultérieurement. L’API synchrone renverra une erreur de délai d’attente (une réponse 408) si la demande prend plus de 60 secondes. Le nombre d’éléments de lot est limité à 100 pour cette API.

POST https://atlas.microsoft.com/search/address/reverse/batch/sync/json?api-version=1.0&subscription-key={subscription-key}

Envoyer une demande de lot asynchrone

L’API asynchrone est appropriée pour le traitement de grands volumes de requêtes de recherche relativement complexes

  • Il permet la récupération des résultats dans un appel séparé (plusieurs téléchargements sont possibles).
  • L’API asynchrone est optimisée pour la fiabilité et n’est pas censée être exécutée dans un délai d’attente.
  • Le nombre d’éléments de lot est limité à 10 000 pour cette API.

Lorsque vous effectuez une requête à l’aide de la requête Async, par défaut, le service retourne un code de réponse 202 le long d’une URL de redirection dans le champ d’emplacement de l’en-tête de réponse. Cette URL doit être vérifiée régulièrement jusqu’à ce que les données de réponse ou les informations d’erreur soient disponibles. Les réponses asynchrones sont stockées pendant 14 jours. L’URL de redirection renvoie une réponse 404 si elle est utilisée après la période d’expiration.

Notez que la demande de lot asynchrone est une demande longue. Voici une séquence typique d’opérations :

  1. le Client envoie une POST demande de lot d’adresses de recherche à Azure Maps

  2. Le serveur répondra avec l’un des éléments suivants :

    La 202 Accepted demande http-batch a été acceptée.

    HTTP Error -une erreur s’est produite lors du traitement de votre requête de lot. Il peut s’agir d’un 400 Bad Request ou de tout autre Error code d’État.

  3. Si la demande de lot a été acceptée avec succès, l' Location en-tête de la réponse contient l’URL permettant de télécharger les résultats de la requête de lot. Cet URI d’État ressemble à ce qui suit :

    GET https://atlas.microsoft.com/search/address/reverse/batch/{batch-id}?api-version=1.0&subscription-key={subscription-key}
  1. Le client émet une GET requête sur l' URL de téléchargement obtenue à l’étape 3 pour télécharger les résultats du lot.

Corps de publication pour la demande de lot

Pour envoyer des requêtes de retour d’adresse de recherche , vous allez utiliser une requête dans POST laquelle le corps de la demande contiendra le batchItems tableau au json format et l' Content-Type en-tête sera défini sur application/json . Voici un exemple de corps de demande contenant 5 requêtes d' annulation d’adresse de recherche :

{
    "batchItems": [
        {"query": "?query=48.858561,2.294911"},
        {"query": "?query=47.639765,-122.127896&radius=5000&limit=2"},
        {"query": "?query=47.621028,-122.348170"},
        {"query": "?query=43.722990,10.396695"},
        {"query": "?query=40.750958,-73.982336"}
    ]
}

Une requête d' inversion d’adresse de recherche dans un lot est simplement une URL partielle sans le protocole, l’URL de base, le chemin d’accès, la version d’API et la clé d’abonnement. Il peut accepter n’importe quel paramètre d’URIde retour d’adresse de recherche pris en charge. Les valeurs de chaîne dans la requête inversée d’adresse de recherche doivent être correctement placées dans une séquence d’échappement (par exemple, «le caractère doit être placé dans une séquence d’échappement avec \ ) et être correctement encodé en URL.

L’API Async permet à l’appelant de traiter jusqu’à 10 000 requêtes et l’API de synchronisation jusqu’à 100 requêtes, et le lot doit contenir au moins 1 requête.

Télécharger les résultats asynchrones par lot

Pour télécharger les résultats de lot asynchrones, vous devez émettre une GET demande au point de terminaison de téléchargement par lot. Cette URL de téléchargement peut être obtenue à partir de l' Location en-tête d’une POST demande de lot réussie et se présente comme suit :

https://atlas.microsoft.com/search/address/reverse/batch/{batch-id}?api-version=1.0&subscription-key={subscription-key}

Voici la séquence classique des opérations de téléchargement des résultats du lot :

  1. Le client envoie une GET demande à l’aide de l' URL de téléchargement.

  2. Le serveur répondra avec l’un des éléments suivants :

    La 202 Accepted requête http-batch a été acceptée, mais elle est toujours en cours de traitement. Réessayez plus tard.

    HTTP 200 OK -demande de lots traitée avec succès. Le corps de la réponse contient tous les résultats de lot.

Modèle de réponse par lot

Le contenu des données retournées est similaire pour les demandes Async et Sync. Lors du téléchargement des résultats d’une demande de lot asynchrone, si le lot a terminé le traitement, le corps de la réponse contient la réponse du lot. Cette réponse par lot contient un summary composant qui indique le totalRequests qui fait partie de la requête de lot d’origine et, par exemple, les successfulRequests requêtes qui ont été exécutées avec succès. La réponse par lot inclut également un batchItems tableau qui contient une réponse pour chaque requête de la requête de lot. batchItemsContient les résultats dans l’ordre exact où les requêtes d’origine ont été envoyées dans la requête de lot. Chaque élément dans batchItems contient statusCode les response champs et. Chaque response dans batchItems est de l’un des types suivants :

  • SearchAddressReverseResponse -Si la requête s’est terminée correctement.

  • Error -Si la requête a échoué. Dans ce cas, la réponse contient un code et un message .

Voici un exemple de réponse par lot avec 2 réussites et 1 résultat d' échec :

{
    "summary": {
        "successfulRequests": 2,
        "totalRequests": 3
    },
    "batchItems": [
        {
            "statusCode": 200,
            "response":
            {
                "summary": {
                    "queryTime": 11
                },
                "addresses": [
                    {
                        "address": {
                            "country": "France",
                            "freeformAddress": "Avenue Anatole France, 75007 Paris"
                        },
                        "position": "48.858490,2.294820"
                    }
                ]
            }
        },
        {
            "statusCode": 200,
            "response":
            {
                "summary": {
                    "queryTime": 1
                },
                "addresses": [
                    {
                        "address": {
                            "country": "United States of America",
                            "freeformAddress": "157th Pl NE, Redmond WA 98052"
                        },
                        "position": "47.640470,-122.129430"
                    }
                ]
            }
        },
        {
            "statusCode": 400,
            "response":
            {
                "error":
                {
                    "code": "400 BadRequest",
                    "message": "Bad request: one or more parameters were incorrectly specified or are mutually exclusive."
                }
            }
        }
    ]
}
Post Search Along Route

S’applique à: niveaux tarifaires S0 et S1.

La recherche sur le point de terminaison de routage vous permet d’effectuer une recherche approximative de POI sur un itinéraire spécifié. Cette recherche est limitée en spécifiant la maxDetourTime mesure de limitation.

Pour envoyer les points de route, vous allez utiliser une POST demande dans laquelle le corps de la demande contient l' route objet représenté comme GeoJSON LineString type et l' Content-Type en-tête est défini sur application/json . Chaque point de routage dans route est représenté sous la forme d’un GeoJSON Position type, c’est-à-dire un tableau dans lequel la valeur de longitude est suivie de la valeur de Latitude et la valeur d' altitude est ignorée. routeDoit contenir au moins 2 points d’itinéraire.

Il est possible que l’itinéraire d’origine soit modifié, certains points peuvent être ignorés. Si l’itinéraire qui traverse le point trouvé est plus rapide que celui d’origine, la detourTime valeur de la réponse est négative.

Post Search Fuzzy Batch

Rechercher une API de lot flou

S’applique à: niveau tarifaire S1.

L’API de lot d’adresses de recherche envoie des lots de requêtes pour Rechercher des API floues à l’aide d’un simple appel d’API. Vous pouvez appeler l’API de traitement par lots d’adresses de recherche pour exécuter de façon asynchrone (asynchrone) ou synchrone (synchronisation). L’API Async permet à l’appelant de traiter jusqu’à 10 000 requêtes et l’API de synchronisation jusqu’à 100 requêtes.

Envoyer une demande de lot synchrone

L’API synchrone est recommandée pour les requêtes de lots légères. Lorsque le service reçoit une demande, il répond dès que les éléments du lot sont calculés et il n’est pas possible de récupérer les résultats ultérieurement. L’API synchrone renverra une erreur de délai d’attente (une réponse 408) si la demande prend plus de 60 secondes. Le nombre d’éléments de lot est limité à 100 pour cette API.

POST https://atlas.microsoft.com/search/fuzzy/batch/sync/json?api-version=1.0&subscription-key={subscription-key}

Envoyer une demande de lot asynchrone

L’API asynchrone est appropriée pour le traitement de grands volumes de requêtes de recherche relativement complexes

  • Il permet la récupération des résultats dans un appel séparé (plusieurs téléchargements sont possibles).
  • L’API asynchrone est optimisée pour la fiabilité et n’est pas censée être exécutée dans un délai d’attente.
  • Le nombre d’éléments de lot est limité à 10 000 pour cette API.

Lorsque vous effectuez une requête à l’aide de la requête Async, par défaut, le service retourne un code de réponse 202 le long d’une URL de redirection dans le champ d’emplacement de l’en-tête de réponse. Cette URL doit être vérifiée régulièrement jusqu’à ce que les données de réponse ou les informations d’erreur soient disponibles. Les réponses asynchrones sont stockées pendant 14 jours. L’URL de redirection renvoie une réponse 404 si elle est utilisée après la période d’expiration.

Notez que la demande de lot asynchrone est une demande longue. Voici une séquence typique d’opérations :

  1. le Client envoie une POST demande de lot d’adresses de recherche à Azure Maps

  2. Le serveur répondra avec l’un des éléments suivants :

    La 202 Accepted demande http-batch a été acceptée.

    HTTP Error -une erreur s’est produite lors du traitement de votre requête de lot. Il peut s’agir d’un 400 Bad Request ou de tout autre Error code d’État.

  3. Si la demande de lot a été acceptée avec succès, l' Location en-tête de la réponse contient l’URL permettant de télécharger les résultats de la requête de lot. Cet URI d’État ressemble à ce qui suit :

    GET https://atlas.microsoft.com/search/fuzzy/batch/{batch-id}?api-version=1.0&subscription-key={subscription-key}
  1. Le client émet une GET requête sur l' URL de téléchargement obtenue à l’étape 3 pour télécharger les résultats du lot.

Corps de publication pour la demande de lot

Pour envoyer des requêtes floues de recherche , vous allez utiliser une POST requête dans laquelle le corps de la demande contiendra le batchItems tableau au json format et l' Content-Type en-tête sera défini sur application/json . Voici un exemple de corps de demande contenant 5 requêtes approximatives de recherche :

{
    "batchItems": [
        {"query": "?query=atm&lat=47.639769&lon=-122.128362&radius=5000&limit=5"},
        {"query": "?query=Statue Of Liberty&limit=2"},
        {"query": "?query=Starbucks&lat=47.639769&lon=-122.128362&radius=5000"},
        {"query": "?query=Space Needle"},
        {"query": "?query=pizza&limit=10"}
    ]
}

Une requête de recherche floue dans un lot n’est qu’une URL partielle sans le protocole, l’URL de base, le chemin d’accès, la version d’API et la clé d’abonnement. Il peut accepter les paramètresd’URI approximatifs de recherche pris en charge. Les valeurs de chaîne dans la requête de recherche floue doivent être correctement placées dans une séquence d’échappement (par exemple, «le caractère doit être placé dans une séquence d’échappement avec \ ) et être correctement encodé en URL.

L’API Async permet à l’appelant de traiter jusqu’à 10 000 requêtes et l’API de synchronisation jusqu’à 100 requêtes, et le lot doit contenir au moins 1 requête.

Télécharger les résultats asynchrones par lot

Pour télécharger les résultats de lot asynchrones, vous devez émettre une GET demande au point de terminaison de téléchargement par lot. Cette URL de téléchargement peut être obtenue à partir de l' Location en-tête d’une POST demande de lot réussie et se présente comme suit :

https://atlas.microsoft.com/search/fuzzy/batch/{batch-id}?api-version=1.0&subscription-key={subscription-key}

Voici la séquence classique des opérations de téléchargement des résultats du lot :

  1. Le client envoie une GET demande à l’aide de l' URL de téléchargement.

  2. Le serveur répondra avec l’un des éléments suivants :

    La 202 Accepted requête http-batch a été acceptée, mais elle est toujours en cours de traitement. Réessayez plus tard.

    HTTP 200 OK -demande de lots traitée avec succès. Le corps de la réponse contient tous les résultats de lot.

Modèle de réponse par lot

Le contenu des données retournées est similaire pour les demandes Async et Sync. Lors du téléchargement des résultats d’une demande de lot asynchrone, si le lot a terminé le traitement, le corps de la réponse contient la réponse du lot. Cette réponse par lot contient un summary composant qui indique le totalRequests qui fait partie de la requête de lot d’origine et, par exemple, les successfulRequests requêtes qui ont été exécutées avec succès. La réponse par lot inclut également un batchItems tableau qui contient une réponse pour chaque requête de la requête de lot. batchItemsContient les résultats dans l’ordre exact où les requêtes d’origine ont été envoyées dans la requête de lot. Chaque élément dans batchItems contient statusCode les response champs et. Chaque response dans batchItems est de l’un des types suivants :

  • SearchFuzzyResponse -Si la requête s’est terminée correctement.

  • Error -Si la requête a échoué. Dans ce cas, la réponse contient un code et un message .

Voici un exemple de réponse par lot avec 2 réussites et 1 résultat d' échec :

{
    "summary": {
        "successfulRequests": 2,
        "totalRequests": 3
    },
    "batchItems": [
        {
            "statusCode": 200,
            "response":
            {
                "summary": {
                    "query": "atm"
                },
                "results": [
                    {
                        "type": "POI",
                        "poi": {
                            "name": "ATM at Wells Fargo"
                        },
                        "address": {
                            "country": "United States Of America",
                            "freeformAddress": "3240 157th Ave NE, Redmond, WA 98052"
                        }
                    }
                ]
            }
        },
        {
            "statusCode": 200,
            "response":
            {
                "summary": {
                    "query": "statue of liberty"
                },
                "results": [
                    {
                        "type": "POI",
                        "poi": {
                            "name": "Statue of Liberty"
                        },
                        "address": {
                            "country": "United States Of America",
                            "freeformAddress": "New York, NY 10004"
                        }
                    }
                ]
            }
        },
        {
            "statusCode": 400,
            "response":
            {
                "error":
                {
                    "code": "400 BadRequest",
                    "message": "Bad request: one or more parameters were incorrectly specified or are mutually exclusive."
                }
            }
        }
    ]
}
Post Search Inside Geometry

S’applique à: niveaux tarifaires S0 et S1.

Le point de terminaison Geometry de recherche vous permet d’effectuer une recherche de forme libre à l’intérieur d’une seule géométrie ou de plusieurs d’entre elles. Les résultats de la recherche qui se trouvent dans les géométries/géométries sont retournés.

Pour envoyer la géométrie, vous allez utiliser une POST requête dans laquelle le corps de la demande contient l' geometry objet représenté comme GeoJSON type et l' Content-Type en-tête est défini sur application/json . Les fonctionnalités géographiques à rechercher peuvent être modélisées en tant que géométries polygonales et/ou de cercle représentées à l’aide de l’un des GeoJSON types suivants :

  • FeatureCollection géojson
    geometryPeut être représenté en tant qu' GeoJSON FeatureCollection objet. Il s’agit de l’option recommandée si la géométrie contient à la fois des polygones et des cercles. FeatureCollectionPeut contenir un maximum de 50 GeoJSON Feature objets. Chaque Feature objet doit représenter un polygone ou un cercle avec les conditions suivantes :
    • Un Feature objet pour la géométrie Polygon peut avoir un maximum de 50 coordonnées et ses propriétés doivent être vides.
    • Un Feature objet pour la géométrie de cercle est constitué d’un Centre représenté à l’aide d’un GeoJSON Point type et d’une valeur de rayon (en mètres) qui doit être spécifiée dans les propriétés de l’objet avec la propriété de sous-type dont la valeur doit être « Circle ».

    Pour obtenir un exemple de représentation, consultez la section exemples ci-dessous FeatureCollection .

  • GeometryCollection géojson
    geometryPeut être représenté en tant qu' GeoJSON GeometryCollection objet. Il s’agit de l’option recommandée si la géométrie contient uniquement une liste de polygones. GeometryCollectionPeut contenir un maximum de 50 GeoJSON Polygon objets. Chaque Polygon objet peut avoir un maximum de 50 coordonnées. Pour obtenir un exemple de représentation, consultez la section exemples ci-dessous GeometryCollection .

  • Polygone géojson
    geometryPeut être représenté en tant qu' GeoJSON Polygon objet. Il s’agit de l’option recommandée si la géométrie contient un seul polygone. L' Polygon objet peut avoir un maximum de 50 coordonnées. Pour obtenir un exemple de représentation, consultez la section exemples ci-dessous Polygon .

.