Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Longitude not being recognized as negative #10

Closed
mlbelobraydi opened this issue Sep 3, 2020 · 4 comments
Closed

Longitude not being recognized as negative #10

mlbelobraydi opened this issue Sep 3, 2020 · 4 comments

Comments

@mlbelobraydi
Copy link
Owner

mlbelobraydi commented Sep 3, 2020

@skylerbast, I'll be pushing the bytes version of the code and I'm not sure if the values are signed or unsigned. It is now capturing the last digits to the value, but I'm not sure the below section is working correctly.

If the penultimate nibble == 0xD, then the number is negative. Otherwise,
it is either positive or unsigned.
val = (val * (-1 if signed_raw[-1] >> 4 == 0xD else 1)) / 10**decimal

Would it be possible to chat with you on how this is suppose to work?

@mlbelobraydi
Copy link
Owner Author

@skylerbast
Copy link
Contributor

Sorry for the delay responding -- I took a look at the RRC file and it looks like the code is working correctly but that the data they're providing is not actually stored as a negative number. I'm not really familiar with how these coordinate systems work, but is it possible that the RRC is entering it as a positive number and just assuming that we know it should be negative?

That code is checking to see if the last nibble in the binary representation of the number is 0xD; if it is that means that the number is negative (this is how the Signed field is defined in COBOL), and in the database files they provide, it seems like it is usually 0xC.

@mlbelobraydi
Copy link
Owner Author

but is it possible that the RRC is entering it as a positive number and just assuming that we know it should be negative

@skylerbast, I think that is what is happening. I have added a small if statement that if the signed value isn't negative and the name is longitude to multiply by -1. It isn't ideal, but it is an ok work around. At least the final decimal precision in now being captured. --Matt

@mlbelobraydi
Copy link
Owner Author

Fixed in the pic_signed function as a work around for TXRRC and closing this issue:

def pic_signed(signed,name,decimal=0): #replacement for pic_latlong and pic_coord
# Converts an EBCDIC Signed number to Python float
# 'signed' must be EBCDIC-encoded raw bytes -- this will not work
# if the data has been converted to ASCII.
## info here http://www.3480-3590-data-conversion.com/article-signed-fields.html
signed_raw = array('B', signed);
val = float(0);

# Bytes 1 to n-1 are stored as plain EBCDIC encoded digits
for i in signed_raw:
    val = val * 10 + (i & 0x0F)


# If the penultimate nibble == 0xD, then the number is negative. Otherwise,
# it is either positive or unsigned.
val = (val * (-1 if signed_raw[-1] >> 4 == 0xD else 1)) / 10**decimal

##TXRRC signs longitude as a positive value with 0xC and requires transformation to a negative number
if 'LONGITUDE' in name and val > 0: ##This is only appropriate for western hemisphere
    val = -val

return val

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants