none
Missing States in GeoDataAPIManager.getBoundary results RRS feed

  • Question

  • Modifying the example shown at: https://msdn.microsoft.com/en-us/library/mt712877.aspx I am attempting to retrieve the boundaries for States in the United States of America.

    If I pass a list of states in the form [ 'AA', 'AK', .......... 'WV', 'WY' ] and specify entityType: 'AdminDivision1' the returned results are missing boundaries for 'UT' (Utah) and 'LA' (Louisiana).

    I can see from another thread that the entityType may be being ignored for selection?? (thread reference https://social.msdn.microsoft.com/Forums/en-US/19f2a70e-bc45-47e2-9484-d19861828050/missing-county-in-boundary-polygon-result?forum=bingmapsservices)

    I have tried querying by State name (Washington is not returned), FIPS CODE etc. but there does not appear to be a code that consistently returns all States. In fact the only way I can return a complete list seems to be by creating a patchwork list of mixed non- standard codes, for example 'State of Louisiana' to force a specific boundary.

    Am I missing something??

    Is there a consistent/standard geocode that I can use which will guarantee that a specific boundary is returned?






    • Edited by AndrewWiles Tuesday, August 9, 2016 3:22 PM
    Tuesday, August 9, 2016 3:16 PM

Answers

  • The entity type is not used as part of the geocoding. Your query is geocoder on its own and then its coordinate is used to retrieve the boundary type you request. This allows you to do things like pass in am address and retrieve its zip code boundary. This is what the docs state.

    If you want to get all US state boundaries there is a US Census data source that you can use with the Query API and retrieve all state boundaries with a single request. Here is a code sample http://www.bing.com/api/maps/sdk/mapcontrol/isdk#sdsChoroplethMap+JS


    [Blog] [twitter] [LinkedIn]

    Wednesday, August 10, 2016 4:07 AM
  • This is a new data source that is managed by the Bing Maps team and it contains 2010 census data. We will be documenting it soon. Documentation efforts have been prioritized for v8 currently. Since this is census data, it is not owned by Microsoft.

    In regards to entity type and geodata, a large percentage of the queries that are passed into that service are of different entity types. Street address are often used to get its parent boundaries. You can however work around this if you wish by calling the geocoding service first on its own and limiting the results to the specified entity type and then pass ots coordinates into the geodata API request. This wouldn't make much difference in terms of performance and would generate the same number of transactions.

    i


    [Blog] [twitter] [LinkedIn]

    • Proposed as answer by Ricky_Brundritt Wednesday, August 10, 2016 1:22 PM
    • Marked as answer by AndrewWiles Wednesday, August 10, 2016 1:42 PM
    Wednesday, August 10, 2016 1:22 PM

All replies

  • The boundaries do exist. The issue comes down to geocoding. Here is an explanation from the documentation: https://msdn.microsoft.com/en-us/library/mt712862.aspx

    If the location value is a string, it will be geocoded and the coordinates of the result will be used to find a boundary of the specified entityType that intersects with this coordinate.

    For example, if the specified location value is "Seattle", and the entityType option is set to "CountryRegion", the border of the USA will be returned since the geocoded coordinate for Seattle is within the "CountryRegion" of the USA.

    With this in mind, you will find that if you geocode "LA" that the geocoder currently returns a result for "Los Angeles", which is then likely returning a boundary for California. It is best to use full state names in most cases (Washington is a bit of an issue as Washington DC is the more commonly expected result for that term, however searching for Washington State or WA in that case works well). There are some planned improvements coming to the geocoder over the next few months which will help address some of these issues.


    [Blog] [twitter] [LinkedIn]


    Tuesday, August 9, 2016 7:15 PM
  • Los Angeles is not of entity type AdminDivision1, nor is Washington DC, I believe these should have an entity type of PopulatedPlace. This therefore sounds like a bug by your description. If the interface honored the entity type consistently I would be happy.

    It would be even better if it were possible to specify an entity type of AdminDivision1 and a query of 'USA' and have all the states returned without having to list them separately.


    • Edited by AndrewWiles Wednesday, August 10, 2016 12:21 AM
    Wednesday, August 10, 2016 12:20 AM
  • The entity type is not used as part of the geocoding. Your query is geocoder on its own and then its coordinate is used to retrieve the boundary type you request. This allows you to do things like pass in am address and retrieve its zip code boundary. This is what the docs state.

    If you want to get all US state boundaries there is a US Census data source that you can use with the Query API and retrieve all state boundaries with a single request. Here is a code sample http://www.bing.com/api/maps/sdk/mapcontrol/isdk#sdsChoroplethMap+JS


    [Blog] [twitter] [LinkedIn]

    Wednesday, August 10, 2016 4:07 AM
  • Ricky, thank you for your help.

    I had looked at the Choropleth example but when I followed through to the public data sources (Query URLs) that the example uses these seem to be a mess of undocumented uploads qualified only as "This data source is not owned by Microsoft". For the application I am developing I need a Microsoft supported data source. Is there a Microsoft supported Query URL that can be used for the purpose of boundary retrieval?

    BTW: Whilst I can understand that the geocoding implementation does not currently use entityType for retrieval it seems that this would be a useful option. If the caller knows what type of entity they are looking for this would remove a significant element of "chance" which is not a good thing for an API. 

    • Edited by AndrewWiles Wednesday, August 10, 2016 9:54 AM
    Wednesday, August 10, 2016 9:31 AM
  • This is a new data source that is managed by the Bing Maps team and it contains 2010 census data. We will be documenting it soon. Documentation efforts have been prioritized for v8 currently. Since this is census data, it is not owned by Microsoft.

    In regards to entity type and geodata, a large percentage of the queries that are passed into that service are of different entity types. Street address are often used to get its parent boundaries. You can however work around this if you wish by calling the geocoding service first on its own and limiting the results to the specified entity type and then pass ots coordinates into the geodata API request. This wouldn't make much difference in terms of performance and would generate the same number of transactions.

    i


    [Blog] [twitter] [LinkedIn]

    • Proposed as answer by Ricky_Brundritt Wednesday, August 10, 2016 1:22 PM
    • Marked as answer by AndrewWiles Wednesday, August 10, 2016 1:42 PM
    Wednesday, August 10, 2016 1:22 PM
  • Ricky

    Thank you again for your rapid responses, I will take a look at your suggestion regarding calling the geocoding service and then passing the co-ordinates to the geodata api. This sounds like a good generic solution that would also work worldwide.

    It is also good to hear that the CENSUS data source(s) are curated by the BING Maps team.

    I am new to the apis so I am having to go through the pain barrier of trying to fit what the BING Maps team have created to what I am trying to deliver (which is a healthcare business intelligence dashboard). It is extremely helpful to have a highly responsive moderator in the forums.

     

    Wednesday, August 10, 2016 1:51 PM