Using regular+tpad for function 1B resulted more miss than just regular

[ishiland]

Using regular+tpad for function 1B resulted more miss than just regular

[docmarionum1]

Can you give some specific examples of the function calls you're making?

[SPTKL]

geo = g.address(house_number=num, street_name=street, borough_code=borough, mode='regular+tpad')

[docmarionum1]

I tried the same thing and didn't notice anything different. What specific address are you noticing it with?

[SPTKL]

g['1A'](house_number='204-11', street_name='38 ave', borough_code='qn')['Longitude']
g['1A'](house_number='204-11', street_name='38 ave', borough_code='qn', mode='regular+tpad')['Longitude']

the first would return a longitude, the second won't, why is that? I thought regular is the default mode and regular_tpad is the union of regular and tpad, hence the second should return a longitude too

[docmarionum1]

'regular+tpad' isn't an expected input, but as long as mode contains 'tpad' it will set tpad to True. Essentially, 'regular+tpad' == 'tpad'.

As for why the longitude doesn't come back from Geosupport, I'm not sure. If you look at the response there are return codes that indicate that there was a conflict between the PAD and TPAD files.

'Reason Code': '*',
'Reason Code Qualifier': '2',
'Warning Code': '',
'Geosupport Return Code (GRC)': '01',
'Message': 'TPAD BBL USED, NO EXISTING PAD BBL',

'TPAD BIN Status (for DM job)': '',
'TPAD New BIN': '4618783',
'TPAD New BIN Status': '0',
'TPAD Conflict Flag': '2',

It looks like the BIN and BBL associated with that address changed in TPAD. I'm not sure if it's expected behavior in this case to not return latitude and longitude. You'd have to ask the Geosupport developers.

Here's some documentation about TPAD and error codes:

https://nycplanning.github.io/Geosupport-UPG/appendices/appendix17/
https://nycplanning.github.io/Geosupport-UPG/chapters/chapterVI/section11/

Closing as this seems to be an issue with Geosupport itself and not python-geosupport.

[SPTKL]

Thanks