Currently, giving coordinates requires the order to be latitude first, longitude second, even if the Hemisphere (N/S; E/W) is provided.
therefore, while unambigious the parsing of "50°E 10°N" failes.
Mixed precision is not accepted, e.g. "50°7'23"N 10°E" failes, while it should resolve to "50°7'23"N 10°0'0"E"
Hemisphere must be uppercase
while this can be circumvented by calling to_uppercase() on the inputstring, the parser shoud accept "n/s/e/w" as directions aswell
* Currently, giving coordinates requires the order to be latitude first, longitude second, even if the Hemisphere (N/S; E/W) is provided.
therefore, while unambigious the parsing of "50°E 10°N" failes.
* Mixed precision is not accepted, e.g. "50°7'23\"N 10°E" failes, while it should resolve to "50°7'23\"N 10°0'0\"E"
* Hemisphere must be uppercase
while this can be circumvented by calling to_uppercase() on the inputstring, the parser shoud accept "n/s/e/w" as directions aswell
Currently, giving coordinates requires the order to be latitude first, longitude second, even if the Hemisphere (N/S; E/W) is provided.
therefore, while unambigious the parsing of "50°E 10°N" failes.
Mixed precision is not accepted, e.g. "50°7'23"N 10°E" failes, while it should resolve to "50°7'23"N 10°0'0"E"
Hemisphere must be uppercase
while this can be circumvented by calling to_uppercase() on the inputstring, the parser shoud accept "n/s/e/w" as directions aswell
Hi, I don't need these so I won't implement that, but feel free to make a merge request (with unit tests)