none
Location REST API not working correctly (not showing house number) for Czech Republic and other states RRS feed

  • Question

  • Hello everybody,

    Since the first of July 2020 the Bing Maps REST API service is not showing house numbers for addresses in Czech Republic, so the EntityType in xml output is always RoadBlock instead of Rooftop. I have tried other countries as well and the problem seems to be affecting Czech Republic, Slovakia and some parts of Poland.

     

    When I type the address in https://www.bing.com/maps/ , it shows exactly what it should. However when I try to find the same address using REST API, I don't get the house number so the location points to the street instead of to the building.

     

    Here is one example that used to work before 1.7.2020 :

     

    https://www.bing.com/maps?osid=b4144887-f68f-45ca-aa1a-95f38c18f46d&cp=49.23404~17.67147&lvl=18&v=2&sV=2&form=S00027

    - bingmap works


    http://dev.virtualearth.net/REST/v1/Locations?c=cs&q=Nad%20V%C3%BDvozem%204849%20Zl%C3%ADn&o=xml&key={api_key}

    -rest location for that address doesn't work

     

    I have tried moving the house number to any location in the url but still nothing.

     

    Does this have anything to do with recent merging of Bing Maps and TomTom ?

    Can someone please help me or provide me with an explanation/solution?

    Any help would be highly appreciated.

    Thanks so much

    Tuesday, August 4, 2020 9:50 AM

All replies

  • Hello,

    You should be able to make a key in the portal that is for the old data source and compare the results to know if the issue is the transition or a data update.

    Sincerely,

    IoTGirl

    Wednesday, August 5, 2020 11:47 PM
    Owner
  • I think we have the same issue in Denmark.

    We use software that (I think) is using the rest API, and that software is able to find cities but not addresses. I don't know when this problem started, but it did work some month ago.  

    I have also tested with webbrowsers:

    When searching with Chrome or Edge a lot of the computers I have tested with, doesn't give any result although autocomplete in the search field is suggesting the correct address.

    When using firefox it always works. 

    Every computer I have tested with used the latest version of Chrome and Edge. On the computers that didn't work I installed firefox which then worked. 


    I think the problem has something todo with the TomTom map, because it never works when the map shows TomTom in the buttom-right corner. When working it shows Here and openstreetmap.  


    I don't know how the bing webpage or webservice choose which map (TomTom or Here) to use, but I don't think that I can do anything to control this from my end.  

    I have also been reading about the merging of Bing maps and TomTom and think you are right that there is a problem that needs to be fixed.

     


    Friday, August 7, 2020 9:10 AM
  • thx, but my account is in  "transitioned" state, that means, all keys are transitioned to new Tomtoms maps.

    I tried to create a new key, but nothing changed. The result is the same, the address is geocoded into the roadblock, not the rooftop.


    Monday, August 10, 2020 6:03 AM
  • Hello,

    It looks like you are using the less precise "q=" that takes a random Query string. If you separate out the address components rather than sending blob text do you get an improved result?

    See https://docs.microsoft.com/en-us/bingmaps/rest-services/locations/find-a-location-by-address

    I am not familiar with addresses in Czech or Denmark but you would use the ISO code for that Country/region

    http://dev.virtualearth.net/REST/v1/Locations?countryRegion={countryRegion}&adminDistrict={adminDistrict}&locality={locality}&postalCode={postalCode}&addressLine={addressLine}&userLocation={userLocation}&userIp={userIp}&usermapView={usermapView}&includeNeighborhood={includeNeighborhood}&maxResults={maxResults}&key={BingMapsKey}

    Sincerely,

    IoTGirl

    Tuesday, August 11, 2020 4:21 AM
    Owner
  • thx for advice. I tried structured query too, but the effect is same.

    http://dev.virtualearth.net/REST/v1/Locations?c=cs&adminDistrict=Zl%C3%ADn&locality=Zl%C3%ADn&postalCode=76005&addressLine=Nad%20v%C3%BDvozem%204849&userLocation=50.073496,14.433536&includeNeighborhood=1&maxResults=5&o=xml&key={key}

    i think that problem isn't with parameters like locality, postalcode, admindistrict, etc.., because unstructured query is able to find road (roadblock entitytype) with confidence=high. 

    as I said before, unstructured query worked well and very precisely for one year till 1 july 2020

    here is example  of the response, with confidence=high, but without house number (juts roadblock), which precission is very bad and it is mostly imposible to use it as a company's car navigation.

    <Response xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/search/local/ws/rest/v1">
    <Copyright>Copyright © 2020 Microsoft and its suppliers. All rights reserved. This API cannot be accessed and the content and any results may not be used, reproduced or transmitted in any manner without express written permission from Microsoft Corporation.</Copyright>
    <BrandLogoUri>http://dev.virtualearth.net/Branding/logo_powered_by.png</BrandLogoUri>
    <StatusCode>200</StatusCode>
    <StatusDescription>OK</StatusDescription>
    <AuthenticationResultCode>ValidCredentials</AuthenticationResultCode>
    <TraceId>6e2460238e4241c5811dd981e5a92f1e|DU00000D5F|0.0.0.1|Ref A: AF23145A3BED422999A363D52EB390A0 Ref B: DB3EDGE1112 Ref C: 2020-08-11T06:20:00Z</TraceId>
    <ResourceSets>
    <ResourceSet>
    <EstimatedTotal>1</EstimatedTotal>
    <Resources>
    <Location>
    <Name>Nad Vývozem, 76005 Zlín</Name>  
    <Point>
    <Latitude>49.2336</Latitude>
    <Longitude>17.67078</Longitude>
    </Point>
    <BoundingBox>
    <SouthLatitude>49.23335</SouthLatitude>
    <WestLongitude>17.66683</WestLongitude>
    <NorthLatitude>49.23609</NorthLatitude>
    <EastLongitude>17.67362</EastLongitude>
    </BoundingBox>
    <EntityType>RoadBlock</EntityType>
    <Address>
    <AddressLine>Nad Vývozem</AddressLine>
    <AdminDistrict>Zlín</AdminDistrict>
    <AdminDistrict2>Zlín</AdminDistrict2>
    <CountryRegion>Czechia</CountryRegion>
    <FormattedAddress>Nad Vývozem, 76005 Zlín</FormattedAddress>
    <Locality>Zlín</Locality>
    <PostalCode>76005</PostalCode>
    </Address>
    <Confidence>High</Confidence>
    <MatchCode>Good</MatchCode>
    <GeocodePoint>
    <Latitude>49.2336</Latitude>
    <Longitude>17.67078</Longitude>
    <CalculationMethod>None</CalculationMethod>
    <UsageType>Display</UsageType>
    </GeocodePoint>
    </Location>
    </Resources>
    </ResourceSet>
    </ResourceSets>
    </Response>
    
    
    

    And here is expected response, which was returned before 1 July 2020:

    Location.Name: Nad Vývozem 4849, 760 05 Zlín, Česká republika 
    Location.Point.Latitude: 49.2340327
    Location.Point.Longtitude: 17.6714752



    Tuesday, August 11, 2020 6:48 AM
  • Hello,

    I have reported this to the GeoLocation team at Microsoft. They work on an Agile schedule so I can not give you a timeline for their review or fix.  I will report back with any details as they are provided.

    UPDATE: The Geocoder team has validated the issue and reproduced the problem. They have a fix in process for the one point / address reported but were unable to find anything systemic for Czech or Denmark.  If there are other points of failure, please provide the specifics so that we can escalate.

    Sincerely,

    IoTGirl





    Tuesday, August 11, 2020 4:22 PM
    Owner
  • Hello,

    The Bing Maps Engineering team has deployed a fix for this issue. Can you confirm that your issue has been addresses?

    Sincerely,

    IoTGirl

    Monday, August 24, 2020 5:14 PM
    Owner
  • I'm sorry for my late reply.
    Addreses, which i reported are geocoded well now after your fix.
    But there remains many adresses which still have reported geocoding issue. Here are some examples:

    Sídliště nad plovárnou 512, Bohosudov, 417 41 Krupka, Česko
    Hvězdova 1689, Praha 4, Nusle, 14000, Česko
    Svojsíkova 514, Městec Králové 28903, Česko
    Husova 819, 73301 Karviná, Česko
    generála Píky 319, 77900 Olomouc, Česko
    
    Melč 1, 74784 Melč, Česko
    Ublo 99, 76312 Ublo, Česko
    Šatov 456, 67122 Šatov, Česko
    Marie Majerové 48, Křelov 78336, Česko
    Průmyslová 389, 53301 Studánka, Česko
    Čechova 314, 58001 Havlíčkův Brod, Česko
    Dluhonská 2914, 75002 Přerov, Česko
    
    Jána Jonáša 1,84302 Bratislava,Slovensko
    

    Can you have look at it please? May be it could help to find some clue for system issue.

    Sincerely,
    J.Kadlecek

    Monday, August 31, 2020 12:55 PM
  • Hi Kadlecek,

    These are being looked at as potentially systemic but we have not found the pattern as yet.  Can you confirm that these are also returning "roadblock"?

    I can try the calls myself but as these are not North American addresses I am having a bit of difficulty converting them into the calls.  Do you have the formatted calls without the key that I can use?

    Sincere thanks,

    IoTGirl


    Wednesday, September 2, 2020 9:19 PM
    Owner
  • Hi IoTGirl,

    European full address format is usually in this form:  

    {street name} {house number}, {city} {postal code}, {country}

    Here is full URL for endpoint Location in REST API  with filled address:

    dev.virtualearth.net/REST/v1/Locations?c=cs&q=Marie%20Majerové%2048,%20Křelov%2078336,%20Česko&o=xml&key={binkey}

    you can try to fill  to the parameter q (query) all addresses which I reported in my las reply. All of them return roadblock.

    As a example address "Marie Majerové 48, Křelov 78336, Česko"  return this response:

    <?xml version="1.0" encoding="ISO-8859-1"?>
    <Response xmlns="http://schemas.microsoft.com/search/local/ws/rest/v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <Copyright>Copyright © 2020 Microsoft and its suppliers. All rights reserved. This API cannot be accessed and the content and any results may not be used, reproduced or transmitted in any manner without express written permission from Microsoft Corporation.</Copyright>
    <BrandLogoUri>http://dev.virtualearth.net/Branding/logo_powered_by.png</BrandLogoUri>
    <StatusCode>200</StatusCode>
    <StatusDescription>OK</StatusDescription>
    <AuthenticationResultCode>ValidCredentials</AuthenticationResultCode>
    <TraceId>e52052f6bbdb4014926fffe6ba194a4b|DU00000D65|0.0.0.1|Ref A: 2DE9FCB3CA0B45D3B2FE055E2EF202FE Ref B: DB3EDGE1014 Ref C: 2020-09-04T10:01:17Z</TraceId>
    <ResourceSets>
    <ResourceSet>
    <EstimatedTotal>1</EstimatedTotal>
    <Resources>
    <Location>
    <Name>Marie Majerové, 78336 Křelov-Břuchotín</Name>
    <Point>
    <Latitude>49.61621</Latitude>
    <Longitude>17.20031</Longitude>
    </Point>
    <BoundingBox>
    <SouthLatitude>49.61581</SouthLatitude>
    <WestLongitude>17.1981</WestLongitude>
    <NorthLatitude>49.61634</NorthLatitude>
    <EastLongitude>17.20285</EastLongitude>
    </BoundingBox>
    <EntityType>RoadBlock</EntityType>
    <Address>
    <AddressLine>Marie Majerové</AddressLine>
    <AdminDistrict>Olomouc</AdminDistrict>
    <AdminDistrict2>Olomouc</AdminDistrict2>
    <CountryRegion>Czechia</CountryRegion>
    <FormattedAddress>Marie Majerové, 78336 Křelov-Břuchotín</FormattedAddress>
    <Locality>Křelov-Břuchotín</Locality>
    <PostalCode>78336</PostalCode>
    </Address>
    <Confidence>High</Confidence>
    <MatchCode>Good</MatchCode>
    <GeocodePoint>
    <Latitude>49.61621</Latitude>
    <Longitude>17.20031</Longitude>
    <CalculationMethod>None</CalculationMethod>
    <UsageType>Display</UsageType>
    </GeocodePoint>
    </Location>
    </Resources>
    </ResourceSet>
    </ResourceSets>
    </Response>

    Friday, September 4, 2020 10:04 AM
  • Thanks Kadlecek,

    It is the special character strings that are a unique challenge.  We don't have many of those in Canada, where I am located, except in Quebec. 

    I have escalated these to the geocoder team for review and will let you know when I have any info back.  If you hit more of these "roadblocks" please share them here.


    Friday, September 4, 2020 3:09 PM
    Owner
  • Hi,
    I have next example of addresses with "missing roadblock" problem. As I mentioned before, this is only example. It is not all  problematic addresses.


    1) Addresses in format: {house number}, {city - small village} {postal code}, {country} )

    77, Rychnovek 55225, Česko    
    138, Velká nad Veličkou 69674, Česko
    71, Trnov 51801, Česko 
    79, Zábeštní Lhota 75127, Česko   
    

    2) Addresses in format: {street} {house number}, {city} {postal code}, {country} )

    Holandská 355, Praha 10100, Česko
    Křenova 438, Praha 16200, Česko   
    Náměstí Míru 206, Vracov 69642, Česko
    Kožná 488, Praha 11000, Česko
    Kašparovo náměstí 2271, Praha 18000, Česko
    Hradecká 569, Pardubice 53352, Česko
    V Ráji 175, Jemnice 67531, Česko
    Tyršova 398, Chýnov 39155, Česko
    
    
    



    Monday, September 21, 2020 6:37 AM
  • Hi Kadlecek,

    We believe the issue has been found.  The transition data does not currently support the return of addresses that aren't associated with streets (these are cadastral, positional rather than typical street defined addresses). We will need a fix from the base map provider to update this and we are waiting on them for a timeline at this point.  In the mean time, if there is a street address that can be used, that could be a work around.

    Sincerely,

    IoTGirl


    Friday, September 25, 2020 7:07 AM
    Owner
  • Thank you for your investigation. Please inform me about the progress of the solution.
    Friday, September 25, 2020 8:53 AM
  • Hi Kadlecek,

    I have the first issue still open and then 13 more, one for each of the first set of addresses you provided.  I will let you know as soon as these are considered fixed as they should be assigned back to me as the creator.

    I have a small curiosity that you might be able to answer.  If this is indeed a "Street" based address issue, does Autosuggest work?  We have a sample web address validator and I am curious if it gives you any valid answers for these.  I tried the first one by typing "77, Rychnovek" but I can't tell if any of the suggestions are correct. Can you?

    Sample Link: https://bingmapsv8samples.azurewebsites.net/#Fill%20Address%20Form%20with%20Autosuggest

    Sincerely,

    IoTGirl

    Friday, September 25, 2020 10:30 PM
    Owner
  • Hi IoTGirl
    I tried autosuggest as you mentioned for all "Street" based addressess and it worked well for all of them.
    But it is just an autosuggest. The geocoding problem persists.
    J.



    Wednesday, September 30, 2020 11:28 AM
  • Great! thanks for checking! 
    Thursday, October 1, 2020 4:49 PM
    Owner