julia> deg2dec(-0.0, 30.0, 17.12345)
0.5047565138888889
Doesn’t seem to work very well.
What is the issue, as I don’t get it from your example, sorry. The degrees input should be an integer, not float, and then -0 deg does not exist in data, it is always defined as 0 deg, AFAIK. And in this case the sign should go to the minutes (or seconds, if the minutes are also 0).
1 Like
I suppose the questions are, what is the standard representation? And based on that, what is the bug. Thinking about astronomy specifically, if one were writing a paper, then the position of the sign would always be in front of degrees, even if it were zero, e.g.
DEC = -0d30m17.12345s # the correct way, in a paper
DEC = 0d-30m17.12345s # the wrong way
DEC = -30m17.12345s # the most wrong way
It seems the best solution would be either use the GMT code that @joa-quim provided, or use one of the code patterns that accepts string input, e.g. dms"1°2′3″"deg or dms"12:17:25.3"deg syntax from AstroAngles. Especially considering that DMS coordinates need to be read as strings to begin with.
1 Like
I would also add that this code would need to be refined a bit to handle edge cases such as wrapping around at 360 deg or +/-180 deg for longitude, and disallowing values greater than 90 degrees (or less than -90) for latitude.
It’s seems like I would need to figure out how GMT deals with lat/long coordinates or use AstroAngles so far.
1 Like
And getting back to your original question, I would also add that there is almost certainly a gdal funciton that does this conversion, so it would then be accessible through ArchGDAL, but I’m not familiar enough with either package to know how to code it.
I mean, I would hope so. I’ll have to dig around the ArchGDAL API docs some more, but it couldn’t find anything initially.
EDIT: There’s CoordTransform which I would initially think is related to what I want to do, but I can’t find anything specifically about turning degree coordinates into decimals.
First, it is lon/lat, NOT lat/lon 
GMT does that all the time but normally in its internals. A dd:mm:ss is a string so we can read from file but not (for now) possible via function argument. If we put this in a file
-0:30:17.12345 13S 4344.8 2001-12-12T14:55 2c 1e 44:45N 88.4 The First String
than we can read it with
gmtread("ddmm.txt")
...
Row │ col.1 col.2 col.3 Time col.5 col.6 col.7 col.8 Text
─────┼────────────────────────────────────────────────────────────────────────────────────────────────
1 │ -0.504757 -13.0 4344.8 2001-12-12T14:55:00 0.787402 0.001 44.75 88.4 The First String
GMT also requires that the degree part must be provided, even if 0
Maybe you can show us an example why/where you are actually needing this.
1 Like
This is my code for degree decimal
function deg2dec(d,m,s)
local negdeg = false
if (d < 0) || (m < 0) || (s < 0)
negdeg = true
end
return (negdeg == true ? -1 : 1) * ( abs(d) + (abs(m)/60) + (abs(s)/3600) )
end
It is weird to allow both non-zero degrees and negative minutes, for instance. The negative minutes or negative seconds input to the function should only be allowed when all previous arguments are zero. See the linked Matlab page in my post further above.
I guess maybe to simply this, I found the following:
ArchGDAL.jl has the methods getx and gety which return a spatial location for a GDAL geometry. These number are quite big, represented in Julia as 6.99827e6 and using @printf to get the “regular” representation of that number is something like 6998271.088400.
If I were to plot this on a map, which would be with ArcGIS, would those be properly placed on a map?
UTM y's go from 0 to 10000 km (N hemisphere) so a 6998271.0884 can be a UTM number. But the shapefile also has information about the coordinate system, which is a fundamental must know info.
Again, what are you trying to do? If you try GMT.jl I bet that this will produce something comprehensible.
using GMT
D = gmtread("path/to/shape.shp")
viz(D)
1 Like
I would eventually like to be able to find points in a given range of coordinates that represent a region/country/county/province/terriority/whatever. Based on the data of those points that are within that range I can calculate something, be it sum, average, whatever.
To give an example, say I read some data from a CSV file (it really doesn’t matter what the source is so long as I can do the filter that I want) that has latitude (Float64), longitude (Float64), some name and some numeric value I’m interested in:
using CSV
using DataFrames
df = CSV.read("my_file.csv", DataFrame)
# the dataframe might look something like this
#
# | id | lat | long | numeric_value |
# |------+---------+---------+---------------|
# | xxxx | xxxxxxx | xxxxxxx | 10000 |
It seems like converting degrees to decimals is a tad difficult to get correct, but at the end of the day, the data is in the decimal representation of latitude and longitude. It’s not any special geospatial data type, just a decimal or specially Float64 in Julia.
Do I care to plot the data on the map? Maybe at some point, but that’s not what I care about at the moment.
See gmtselect, inwhichpolygon and others in the GMT manual. But that’s one example. Other packages offer this type of operations as well.
Regarding the degrees-to-dec I still fail to see what is the problem.