sk-zk
commented
1 year ago
othercontains 1 element (...) So, I've just wrapped this in a try_get. This might not be the right thing to do since now since those fields in StreetViewPanorama are not supposed to be None, but it keeps the link information there.
Yeah, that's good. I'll add a note to the documentation that there are rare edge cases where this can happen.
Well… for that pano in particular, the links start at 0 instead of 1 (...) but I'm not quite sure yet if that's the two links in other, or if index 1 is a link and index 2 is something else, or who knows.
They're both links, as indicated by the array indices. The problem is that with all other panos I've seen so far, the first entry in that list is just the parent again, which is why I started enumerating others from 1, but I guess that doesn't always work. I'll fix that
links_rawcontains a link with 1 element (...) inlinks_rawit does not have the second element, for whatever reason
Oh that's weird. The arrows even point in the right direction in the embeddable client
The simple fix here is to just say direction is 0, and the other 3 fields are None because they always seem to be None anyway and aren't used.
I think 0 is not a good default because it suggests that the pano is straight north when in reality the value is missing. I'm gonna try to calculate the missing value from the coordinates, or, if I can't make that work, I'll set them to None.
I don't actually know the cause of the internal API doing this
Google doing Google things 🤷♂️
Google being the silly company that it is, there are some pano IDs which (at the time of writing) are weird, and previously threw errors, so I have attempted to fix them. Two things I have seen go wrong:
othercontains 1 element This seems to happen mostly for scout coverage, in locations like Nepal or Iraq (something I've noticed is that while scout usually leaves the country code blank, countries like these or Mongolia (which is scout in many rural areas (e.g. 5vXx-PnSt_kDim3Tm9yS_g) despite the obvious presence of a car) fill it in, so maybe they're built different for one reason or another but anyway that's enough rambling out of me) For example,75oFcYmZUOnqgvAaX2q-_w. This appears fine when you look at it, navigation works, but with streetlevel, gives an error in_parse_pano_message:othersis just[[[2, 'yCIEQ7o37R49IxNPOkhWgw']], [[2, 'C9aepLhvgmFjRJlP2GxjXQ']]]here. Interesting! No lat/lng for you. So, I've just wrapped this in a try_get. This might not be the right thing to do since now since those fields in StreetViewPanorama are not supposed to be None, but it keeps the link information there. Well… for that pano in particular, the links start at 0 instead of 1 (links_raw =[[0, [None, None, None, 71.3132095336914]], [1, [None, None, None, -112.6307830810547]]]) but I'm not quite sure yet if that's the two links in other, or if index 1 is a link and index 2 is something else, or who knows.links_rawcontains a link with 1 element This seems to happen in various places, I can't see any pattern or common thing going on. For example, VAhJEVyAlZg-QgAnUwcIRA: links_raw =[[1], [2, [None, None, None, 180]]]others[1] =[[2, '900f3jhfBLeqaZlOehoH5g'], None, [[None, None, 6.559818352725746, 3.36942864065604], [31.01354598999023], [184.7613220214844, 87.32682037353516, 358.21533203125]], [None, None, [['Odunlami St', 'en']]]]Index 1 is fine inothers, but inlinks_rawit does not have the second element, for whatever reason. Other example: 2ZYEK3M9r9VF4zcbGAat9Q, links_raw =[[2], [3, [None, None, None, 239.3732147216797]], [1, [None, None, None, 330.4307861328125]]]The simple fix here is to just say direction is 0, and the other 3 fields are None because they always seem to be None anyway and aren't used.
There are quite possibly more examples, these are just locations I've come across in GeoGuessr rather than me specifically looking for them, so I don't actually know the cause of the internal API doing this.