Grammatical improvements and end link creation for Creator articles

Author: stevemunk

articles/azure-maps/creator-facility-ontology.md

@@ -1,8 +1,8 @@
 ---
 title: Azure Maps Creator service geographic scope
 description: Learn about Azure Maps Creator service's geographic mappings in Azure Maps
-author: eriklindeman
-ms.author: eriklind
+author: brendansco
+ms.author: Brendanc
 ms.date: 05/18/2021
 ms.topic: conceptual
 ms.service: azure-maps
@@ -12,7 +12,7 @@ ms.custom: mvc, references_regions
 
 # Creator service geographic scope
 
-Azure Maps Creator is a geographically scoped service. Creator offers a resource provider API that, given an Azure region, creates an instance of Creator data deployed at the geographical level. The mapping from an Azure region to geography happens behind the scenes as described in the table below. For more details on Azure regions and geographies, see [Azure geographies](https://azure.microsoft.com/global-infrastructure/geographies).
+Azure Maps Creator is a geographically scoped service. Creator offers a resource provider API that, given an Azure region, creates an instance of Creator data deployed at the geographical level. The mapping from an Azure region to geography happens behind the scenes as described in the following table. For more information on Azure regions and geographies, see [Azure geographies].
 
 ## Data locations
 
@@ -22,8 +22,9 @@ For disaster recovery and high availability, Microsoft may replicate customer da
 
 The following table describes the mapping between geography and supported Azure regions, and the respective geographic API endpoint. For example, if a Creator account is provisioned in the West US 2 region that falls within the United States geography, all API calls to the Conversion service must be made to `us.atlas.microsoft.com/conversion/convert`.
 
-
 | Azure Geographic areas (geos) | Azure datacenters (regions) | API geographic endpoint |
 |------------------------|----------------------|-------------|
 | Europe| West Europe, North Europe | eu.atlas.microsoft.com |
 |United States | West US 2, East US 2 | us.atlas.microsoft.com |
+
+[Azure geographies]: https://azure.microsoft.com/global-infrastructure/geographies

articles/azure-maps/creator-geographic-scope.md

@@ -2,8 +2,8 @@
 title: Work with indoor maps in Azure Maps Creator
 titleSuffix: Azure Maps Creator
 description: This article introduces concepts that apply to Azure Maps Creator services
-author: eriklindeman
-ms.author: eriklind
+author: brendansco
+ms.author: Brendanc
 ms.date: 04/01/2022
 ms.topic: conceptual
 ms.service: azure-maps

articles/azure-maps/creator-indoor-maps.md

@@ -1,8 +1,8 @@
 ---
 title: Azure Maps long-running operation API V2
 description: Learn about long-running asynchronous V2 background processing in Azure Maps
-author: eriklindeman
-ms.author: eriklind
+author: brendansco
+ms.author: Brendanc
 ms.date: 05/18/2021
 ms.topic: conceptual
 ms.service: azure-maps
@@ -12,11 +12,11 @@ ms.custom: mvc
 
 # Creator Long-Running Operation API V2
 
-Some APIs in Azure Maps use an [Asynchronous Request-Reply pattern](/azure/architecture/patterns/async-request-reply). This pattern allows Azure Maps to provide highly available and responsive services. This article explains Azure Map's specific implementation of long-running asynchronous background processing.
+Some APIs in Azure Maps use an [Asynchronous Request-Reply pattern]. This pattern allows Azure Maps to provide highly available and responsive services. This article explains Azure Map's specific implementation of long-running asynchronous background processing.
 
 ## Submit a request
 
-A client application starts a long-running operation through a synchronous call to an HTTP API. Typically, this call is in the form of an HTTP POST request. When an asynchronous workload is successfully created, the API will return an HTTP `202` status code, indicating that the request has been accepted. This response contains a `Location` header pointing to an endpoint that the client can poll to check the status of the long-running operation.
+A client application starts a long-running operation through a synchronous call to an HTTP API. Typically, this call is in the form of an HTTP POST request. When an asynchronous workload is successfully created, the API returns an HTTP `202` status code, indicating that the request has been accepted. This response contains a `Location` header pointing to an endpoint that the client can poll to check the status of the long-running operation.
 
 ### Example of a success response
 
@@ -26,11 +26,11 @@ Operation-Location: https://atlas.microsoft.com/service/operations/{operationId}
 
 ```
 
-If the call doesn't pass validation, the API will instead return an HTTP `400` response for a Bad Request. The response body will provide the client more information on why the request was invalid.
+If the call doesn't pass validation, the API returns an HTTP `400` response for a Bad Request. The response body provides the client more information on why the request was invalid.
 
 ### Monitor the operation status
 
-The location endpoint provided in the accepted response headers can be polled to check the status of the long-running operation. The response body from operation status request will always contain the `status` and the `created` properties. The `status` property shows the current state of the long-running operation. Possible states include `"NotStarted"`, `"Running"`, `"Succeeded"`, and `"Failed"`. The `created` property shows the time the initial request was made to start the long-running operation. When the state is either `"NotStarted"` or `"Running"`, a `Retry-After` header will also be provided with the response. The `Retry-After` header, measured in seconds, can be used to determine when the next polling call to the operation status API should be made.
+The location endpoint provided in the accepted response headers can be polled to check the status of the long-running operation. The response body from operation status request always contains the `status` and the `created` properties. The `status` property shows the current state of the long-running operation. Possible states include `"NotStarted"`, `"Running"`, `"Succeeded"`, and `"Failed"`. The `created` property shows the time the initial request was made to start the long-running operation. When the state is either `"NotStarted"` or `"Running"`, a `Retry-After` header is also provided with the response. The `Retry-After` header, measured in seconds, can be used to determine when the next polling call to the operation status API should be made.
 
 ### Example of running a status response
 
@@ -46,7 +46,7 @@ Retry-After: 30
 
 ## Handle operation completion
 
-Upon completing the long-running operation, the status of the response will either be `"Succeeded"` or `"Failed"`. All responses will return an HTTP 200 OK code. When a new resource has been created from a long-running operation, the response will also contain a `Resource-Location` header that points to metadata about the resource. Upon a failure, the response will have an `error` property in the body. The error data adheres to the OData error specification.
+Once the long-running operation completes, the status of the response is either `"Succeeded"` or `"Failed"`. All responses return an HTTP 200 OK code. When a new resource has been created from a long-running operation, the response also contains a `Resource-Location` header that points to metadata about the resource. Upon a failure, the response has an `error` property in the body. The error data adheres to the OData error specification.
 
 ### Example of success response
 
@@ -79,3 +79,5 @@ Status: 200 OK
     }
 }
 ```
+
+[Asynchronous Request-Reply pattern]: /azure/architecture/patterns/async-request-reply

articles/azure-maps/creator-long-running-operation-v2.md

@@ -1,8 +1,8 @@
 ---
 title: Azure Maps Long-Running Operation API
 description: Learn about long-running asynchronous background processing in Azure Maps
-author: eriklindeman
-ms.author: eriklind
+author: brendansco
+ms.author: Brendanc
 ms.date: 12/07/2020
 ms.topic: conceptual
 ms.service: azure-maps
@@ -12,11 +12,11 @@ ms.custom: mvc
 
 # Creator Long-Running Operation API
 
-Some APIs in Azure Maps use an [Asynchronous Request-Reply pattern](/azure/architecture/patterns/async-request-reply). This pattern allows Azure Maps to provide highly available and responsive services. This article explains Azure Map's specific implementation of long-running asynchronous background processing.
+Some APIs in Azure Maps use an [Asynchronous Request-Reply pattern]. This pattern allows Azure Maps to provide highly available and responsive services. This article explains Azure Map's specific implementation of long-running asynchronous background processing.
 
 ## Submitting a request
 
-A client application starts a long-running operation through a synchronous call to an HTTP API. Typically, this call is in the form of an HTTP POST request. When an asynchronous workload is successfully created, the API will return an HTTP `202` status code, indicating that the request has been accepted. This response contains a `Location` header pointing to an endpoint that the client can poll to check the status of the long-running operation.
+A client application starts a long-running operation through a synchronous call to an HTTP API. Typically, this call is in the form of an HTTP POST request. When an asynchronous workload is successfully created, the API returns an HTTP `202` status code, indicating that the request has been accepted. This response contains a `Location` header pointing to an endpoint that the client can poll to check the status of the long-running operation.
 
 ### Example of a success response
 
@@ -26,11 +26,11 @@ Location: https://atlas.microsoft.com/service/operations/{operationId}
 
 ```
 
-If the call doesn't pass validation, the API will instead return an HTTP `400` response for a Bad Request. The response body will provide the client more information on why the request was invalid.
+If the call doesn't pass validation, the API returns an HTTP `400` response for a Bad Request. The response body provides the client more information on why the request was invalid.
 
 ### Monitoring the operation status
 
-The location endpoint provided in the accepted response headers can be polled to check the status of the long-running operation. The response body from operation status request will always contain the `status` and the `createdDateTime` properties. The `status` property shows the current state of the long-running operation. Possible states include `"NotStarted"`, `"Running"`, `"Succeeded"`, and `"Failed"`. The `createdDateTime` property shows the time the initial request was made to start the long-running operation. When the state is either `"NotStarted"` or `"Running"`, a `Retry-After` header will also be provided with the response. The `Retry-After` header, measured in seconds, can be used to determine when the next polling call to the operation status API should be made.
+The location endpoint provided in the accepted response headers can be polled to check the status of the long-running operation. The response body from operation status request contains the `status` and the `createdDateTime` properties. The `status` property shows the current state of the long-running operation. Possible states include `"NotStarted"`, `"Running"`, `"Succeeded"`, and `"Failed"`. The `createdDateTime` property shows the time the initial request was made to start the long-running operation. When the state is either `"NotStarted"` or `"Running"`, a `Retry-After` header is also provided with the response. The `Retry-After` header, measured in seconds, can be used to determine when the next polling call to the operation status API should be made.
 
 ### Example of running a status response
 
@@ -46,7 +46,7 @@ Retry-After: 30
 
 ## Handling operation completion
 
-Upon completing the long-running operation, the status of the response will either be `"Succeeded"` or `"Failed"`. When a new resource has been created from a long-running operation, the success response will return an HTTP `201 Created` status code. The response will also contain a `Location` header that points to metadata about the resource. When no new resource has been created, the success response will return an HTTP `200 OK` status code. Upon a failure, the response status code will also be the `200 OK`code. However, the response will have an `error` property in the body. The error data adheres to the OData error specification.
+Once the long-running operation completes, the status of the response is either `"Succeeded"` or `"Failed"`. When a new resource has been created from a long-running operation, the success response returns an HTTP `201 Created` status code. The response also contains a `Location` header that points to metadata about the resource. When no new resource has been created, the success response returns an HTTP `200 OK` status code. Upon a failure, the response status code is also `200 OK`. However, the response has an `error` property in the body. The error data adheres to the OData error specification.
 
 ### Example of success response
 
@@ -80,3 +80,5 @@ Status: 200 OK
     }
 }
 ```
+
+[Asynchronous Request-Reply pattern]: /azure/architecture/patterns/async-request-reply

articles/azure-maps/creator-long-running-operation.md

@@ -42,7 +42,7 @@ If using a tool like [Postman], it should look like this:
 
 :::image type="content" source="./media/tutorial-creator-indoor-maps/stateset-header.png"alt-text="A screenshot of Postman showing the Header tab of the POST request that shows the Content Type Key with a value of application forward slash json.":::
 
-Finally, in the **Body** of the HTTP request, include the style information in raw JSON format, this applies different colors to the `occupied` property depending on its value:
+Finally, in the **Body** of the HTTP request, include the style information in raw JSON format, which applies different colors to the `occupied` property depending on its value:
 
 ```json
 {
@@ -61,13 +61,13 @@ Finally, in the **Body** of the HTTP request, include the style information in r
 }
 ```
 
-After the response returns successfully, copy the `statesetId` from the response body. In the next section, you'll use the `statesetId` to change the `occupancy` property state of the unit with feature `id` "UNIT26". If using Postman, it will appear as follows:
+After the response returns successfully, copy the `statesetId` from the response body. In the next section, you'll use the `statesetId` to change the `occupancy` property state of the unit with feature `id` "UNIT26". If using Postman, it appears as follows:
 
 :::image type="content" source="./media/tutorial-creator-indoor-maps/response-stateset-id.png"alt-text="A screenshot of Postman showing the resource Stateset ID value in the responses body.":::
 
 ## Update a feature state
 
-In this section you will learn how to update the `occupied` state of the unit with feature `id` "UNIT26". To do this, create a new **HTTP PUT Request** calling the [Feature Statesets API]. The request should look like the following URL (replace `{statesetId}` with the `statesetId` obtained in [Create a feature stateset](#create-a-feature-stateset)):
+This section demonstrates how to update the `occupied` state of the unit with feature `id` "UNIT26". To update the `occupied` state, create a new **HTTP PUT Request** calling the [Feature Statesets API]. The request should look like the following URL (replace `{statesetId}` with the `statesetId` obtained in [Create a feature stateset]):
 
 ```http
 https://us.atlas.microsoft.com/featurestatesets/{statesetId}/featureStates/UNIT26?api-version=2.0&subscription-key={Your-Azure-Maps-Subscription-key}
@@ -79,7 +79,7 @@ If using a tool like [Postman], it should look like this:
 
 :::image type="content" source="./media/tutorial-creator-indoor-maps/stateset-header.png"alt-text="A screenshot of the header tab information for stateset creation.":::
 
-Finally, in the **Body** of the HTTP request, include the style information in raw JSON format, this applies different colors to the `occupied` property depending on its value:
+Finally, in the **Body** of the HTTP request, include the style information in raw JSON format, which applies different colors to the `occupied` property depending on its value:
 
 ```json
 {
@@ -96,11 +96,11 @@ Finally, in the **Body** of the HTTP request, include the style information in r
 >[!NOTE]
 > The update will be saved only if the time posted stamp is after the time stamp of the previous request.
 
-Once the HTTP request is sent and the update completes, you'll receive a `200 OK` HTTP status code. If you implemented [dynamic styling] for an indoor map, the update displays at the specified time stamp in your rendered map.
+Once the HTTP request is sent and the update completes, you receive a `200 OK` HTTP status code. If you implemented [dynamic styling] for an indoor map, the update displays at the specified time stamp in your rendered map.
 
 ## Additional information
 
-* For information on how to retrieve the state of a feature using its feature id, see [Feature State - List States].
+* For information on how to retrieve the state of a feature using its feature ID, see [Feature State - List States].
 * For information on how to delete the stateset and its resources, see [Feature State - Delete Stateset].
 * For information on using the Azure Maps Creator [Feature State service] to apply styles that are based on the dynamic properties of indoor map data features, see how to article [Implement dynamic styling for Creator indoor maps].
 
@@ -113,16 +113,24 @@ Learn how to implement dynamic styling for indoor maps.
 > [!div class="nextstepaction"]
 > [dynamic styling]
 
+<!---------   Internal Links     --------------->
+[Create a feature stateset]: #create-a-feature-stateset
+
+<!---------   learn.microsoft.com links     --------------->
 [Access to Creator Services]: how-to-manage-creator.md#access-to-creator-services
-[Query datasets with WFS API]: how-to-creator-wfs.md
-[Stateset API]: /rest/api/maps/v2/feature-state/create-stateset
-[Feature Statesets API]: /rest/api/maps/v2/feature-state/create-stateset
-[Feature statesets]: /rest/api/maps/v2/feature-state
 [Check the dataset creation status]: tutorial-creator-indoor-maps.md#check-the-dataset-creation-status
+[Creator Indoor Maps]: creator-indoor-maps.md
 [dynamic styling]: indoor-map-dynamic-styling.md
-[Feature State - List States]: /rest/api/maps/v2/feature-state/list-states
-[Feature State - Delete Stateset]: /rest/api/maps/v2/feature-state/delete-stateset
-[Feature State service]: /rest/api/maps/v2/feature-state
 [Implement dynamic styling for Creator indoor maps]: indoor-map-dynamic-styling.md
-[Creator Indoor Maps]: creator-indoor-maps.md
+[Query datasets with WFS API]: how-to-creator-wfs.md
+
+<!---------   External Links     --------------->
 [Postman]: https://www.postman.com/
+
+<!---------   REST API Links     --------------->
+[Feature State - Delete Stateset]: /rest/api/maps/v2/feature-state/delete-stateset
+[Feature State - List States]: /rest/api/maps/v2/feature-state/list-states
+[Feature State service]: /rest/api/maps/v2/feature-state
+[Feature Statesets API]: /rest/api/maps/v2/feature-state/create-stateset
+[Feature statesets]: /rest/api/maps/v2/feature-state
+[Stateset API]: /rest/api/maps/v2/feature-state/create-stateset