Geocoding CSV response inconsistent RRS feed

  • Question

  • I've been using a CSV list of locations for geocoding, and am successfully receiving responses. However, the response is also in csv format and seems to be inconsistent, in that sometimes the Latitude and Longitude will be in element offsets [20] and [21], and sometimes in [22] and [23].

    Is there any way to find out with confidence where the Lat and Long data appear in the CSV response? Or can I request an XML response after submitting a CSV request? Either would be fine!


    Thursday, June 28, 2018 1:49 PM

All replies

  • I assume you're talking about Bing Spatial Data Services, although cvs is correct format for input, output is never returned as cvs, by default this is json, but you can also have xml output. Just add output=xml or o=xml to geocode job url as documented here:
    Thursday, June 28, 2018 4:08 PM
  • I am using the output=xml option.

    Using GoogleMaps I can say

    XDocument xdoc = XDocument.Load(response.GetResponseStream())

    and it's fine, I can then access all the xdoc elements as expected. If I try this with the BingMaps response I get the following error:

    Data at the root level is invalid. Line 1, position 1.'

    Following someone else's example, I tried 

    using (Stream receiveStream = response.GetResponseStream())

    This succeeds, but every line I read from the stream is a comma-separated list as follows (and this is a real example):

    15262,fr-FR,,100 Champs-ElyseesParisFrance,,FRA,,,,,,,,,France,,France,,,,46.6218452453613,2.45194888114929,,,Medium,France,CountryRegion,Success,,,

    As I mentioned before, the lat and long locations in this csv list are not consistent.

    I assume that I am misunderstanding something somewhere (not unusual), but I found the GoogleMaps version simple to understand and implement, whereas the BingMaps version seems to have a load of contradictory "documentation" concurrently visible in many places (particularly regarding the "basic" licensing/"billable" vs "non-billable" transactions etc.), and while I can successfully get responses which contain the data I want, I cannot as yet get responses which software can interpret consistently without my personal intervention!

    I may well have missed this in my searches, but is there useable example code somewhere which illustrates not just the xml/json response formats (I can find these), but how to get these responses from the web request?

    Thanks for your advice. 

    PS I based my sample code on Each readline call returns a comma-separated list as above.
    • Edited by Rhaglen Friday, June 29, 2018 9:14 AM
    Friday, June 29, 2018 8:54 AM
  • I think I now understand the discrepancy in CSV offsets in returned data. Item 17 in the list is some sort of Address and is contained within quotation marks. Unfortunately, between these quotation marks there are also commas, and the line.split() statement I was using is not differentiating between commas *separating* elements, and commas contained *within* elements. 

    Incidentally, I implemented the full solution described here, and the "success.txt" file contains repeated lines of csv data. not xml. If it were xml data then this problem would not be a problem!

    • Edited by Rhaglen Friday, June 29, 2018 10:51 AM
    Friday, June 29, 2018 10:51 AM
  • I was wrong. Here are 2 adjacent lines returned in the success.txt file:

    23310,en-GB,,addresspart Angus,,GBR,,,,DD1 2EA,DUNDEE,,addresspart,Scotland,United Kingdom,Dundee City,"addresspart, Dundee, Scotland DD1 2EA",Dundee,DD1 2EA,,56.4628141,-2.9682701,,,High,"addresspart, Dundee, Scotland DD1 2EA",Address,Success,,,
    23327,en-GB,,addresspart Castletown,,GBR,,,,IM9 1LG,Isle of Man,,Castletown,England,United Kingdom,Dorset,"Castletown, Castletown, England DT5 1",Castletown,DT5 1,,,,50.5680657293843,-2.44453825502042,High,"Castletown, Castletown, England DT5 1",RoadBlock,Success,,,

    In both of those, element 16 (0-based) is the quote-enclosed address. Elements 20 and 21 are Lat and Long in the 1st line, whereas elements 22 and 23 are Lat and Long in the 2nd line. The returned Lat & Long in the 2nd line are also incorrect - having been provided with the PostCode IM9 1LG, Bingmaps has decided it knows better, and with "High" probability puts it somewhere in Dorset, as opposed to the Isle of Man.

    Friday, June 29, 2018 1:06 PM