What type of GPS data is this? - gps

I have a CCTR-800 Portable GPS tracker and I'm receiving data from it in the following format:
*130622214449UB05CW9999C00017093214449A28.452306052.197705130622129.0111111111L000000^
*130622214449UA010214449A28.452306052.197705130622129.0111111111L000000^
Someone have an ideia of what format is this?
I know that the first numbers are date/time: 13-06-22 21:44:49.

I found it, it's Viczone's protocol:
http://www.gps-profi.ru/tech/Communication_Protocol_for_VIC-T801.pdf

So if you break the line up into segments based on the letters you end up with something like this
*130622 214449 UB05 CW9999 C00017093214449 A28.452306052.197705130622129.0111111111 L000000
*130622 214449 UA010214449 A28.452306052.197705130622129.0111111111 L000000
I would start with getting a list of coordinates or where the points were recorded and try correspond the points you recorded with the data.
The first grouping is going to be date and time
The second grouping UB / UA / CW / C seems to change based on the line. Does it always alternate like that? Do the numbers change based on location?
The third grouping A seems repeatable and may be location data
The last grouping L seems kinda of useless but it could change based on other parameters. Does it always report back 0?
Can you move to the GPS to from point to point (say one end of your room to the other) and get repeatable or similar numbers?
It would be worth a shoot to look up if anyone else has worked with that type of GPS.

Related

I cannot understand why "in" doesn't work correctly

sp01 is dataframe which contains S&P 500 index. And I have a dataframe,interest, which contains daily interest rate. The two data started from same date, but their size were not same. It's error.
I want to get exact same date, so tried to check every date using "in" function. But "in" function doesn't work well. This is code :
print(sp01.Date[0], type(sp01.Date[0]) )
->1976-06-01, str
print(interest.DATE[0], type(interest.DATE[0]) )
->1976-06-01, str
print(sp01.Date[0] in interest.DATE)
->False
I can never understand why the result becomes False.
Of course, first date of sp01 and interest is totally same,
I checked it too by typing code. So, True should be come out, but False came out. I got mad!!!please Help me.
I solved it! the problem is that "in" function does not work for pandas series data. Those two data are pandas series, so I have to change one of them to list

Valid displayAt() range in GMS

Images can be displayed at a specific location with the DisplayAt() command.
Does anyone know the valid range?
For example, DisplayAt(-9000, -9000) is that valid? What is the total valid range?
Of course in the example the image would not be seen within the GMS frame, but that is exactly what I need.
Thanks
Yes, negative values are completely ok and will indeed "place" the image outside the visible range of the window.
There is nothing like a "valid" range - the coordindates are just numbers. ( There is likely a limit when the value exceeds the value-range of the internallly used variable type to store the coordinates, possiblye long (4 byte signed integer). )
Just be aware that concepts like "front most" window will also apply if an image is outside the "visible" range. Images will f.e. also show up in the ImageBrowser regardless of their position on the workspace. The same is true for iterating through images on a workspace using f.e. CountImageDocuments() and GetImageDocument()
Some commands ( I think ShowImage() ) might have addtional code to ensure that images stay "visible" and might therefore shift the image back into the workspace range. Also using "auto-arrange" will take images from the "off" and place them back into the visible range.
So if you deliberatly use "off-screen" display, this is ok, but it might create some unintended side-effects. What is the exact purpose of using it this way? There might be more suitable concepts. (f.e. one can create imageDocuments and add ImageDisplays to them without the need of showing the imageDocument.) Image may also be temporarilly "hidden". Finally, one might condiser shiftung "unwanted" images onto a separate workspace.

solr geodist() giving wrong distance

I am using geodist() in solr query. following is my query
q=(name:(*)&fl=person_id, name, longitude, lattitude, distance:geodist()&fq={!geofilt}&spatial=true&pt=73.7708441,18.5664871&d=10&sort=geodist() asc&group=true&group.field=person_id&group.format=simple&group.main=true&start=0&rows=15
one of entry in my output is
{
\"personId\": 313403,
\"name\": \"Dev\",
\"longitude\": 73.812498,
\"latitude\": 18.439598,
\"distance\": 6.079763395151475,
}
But when I count distance between both lat long on internet i.e (73.7708441,18.5664871) to (73.812498, 18.439598), It gives me 14.782 km or 9.187 in mile
I searched about solr geodist() but same function and query is used everywhere. Can somebody please tell me whats going wrong here?
Looks like some wires have got crossed somewhere.
If your coordinates should be: (lat: 73.7..., long:18.5...), then solr's distance is correct, and your fields ("latitude" and "longitude") appear to be mislabelled
On the other hand, if it should be (lat: 18.5..., long:73.7...), then the distance you've calculated is correct, and the coordinates are backward in your query, which should be: pt=18.5664871,73.7708441. Pretty sure your LatLonType field would also have to have it backward, so those would need to be fixed and reindexed, as well.
Finally resolved.
There were too mistake
1-pt should be pt=lat, long
2-while putting lat long in solr (by data-config.xml), name of latitude field should be location_0_coordinate and longitude - location_1_coordinate
in my case it was interchanged

Extracting Data from an Area file

I am trying to extract information at a specific location (lat,lon) from different satellite images. These images are were given to me in the AREA format and I cooked up a simple jython script to extract temperature values like so.
While the script works, here is small snippet from it that prints out the data value at a point.
from edu.wisc.ssec.mcidas import AreaFile as af
url="adde://localhost/imagedata?&PORT=8113&COMPRESS=gzip&USER=idv&PROJ=0& VERSION=1&DEBUG=false&TRACE=0&GROUP=FL&DESCRIPTOR=8712C574&BAND=2&LATLON=29.7276 -85.0274 E&PLACE=ULEFT&SIZE=1 1&UNIT=TEMP&MAG=1 1&SPAC=4&NAV=X&AUX=YES&DOC=X&DAY=2012002 2012002&TIME=&POS=0&TRACK=0"
a=af(url);
value=a.getData();
print value
array([[I, [array([I, [array('i', [2826, 2833, 2841, 2853])])])
So what does this mean?
Please excuse me if the question seems trivial, while I am comfortable with python I am really new to dealing with scientific data.
Note
Here is a link to the entire script.
After asking around, I found out that the Area objects returns data in multiples of four. So the very first value is what I am looking for.
Grabbing the value is as simple as :
ar[0][0][0]

Enter date into function without quotes, return date

I'm trying to write a function of this form:
Function cont(requestdate As Date)
cont = requestdate
End Function
Unfortunately, when I enter =cont(12/12/2012) into a cell, I do not get my date back. I get a very small number, which I think equals 12 divided by 12 divided by 2012. How can I get this to give me back the date? I do not want the user to have to enter =cont("12/12/2012").
I've attempted to google for an answer, unfortunately, I have not found anything helpful. Please let me know if my vocabulary is correct.
Let's say my user pulled a report with 3 columns, a, b and c. a has beginning of quarter balances, b has end of quarter balances and c has a first and last name. I want my user to put in column d: =cont(a1,b1,c1,12/12/2012) and make it create something like:
BOQ IS 1200, EOQ IS 1300, NAME IS EDDARD STARK, DATE IS 12/12/2012
So we could load this into a database. I apologize for the lack of info the first time around. To be honest, this function wouldn't save me a ton of time. I'm just trying to learn VBA, and thought this would be a good exercise... Then I got stuck.
Hard to tell what you are really trying to accomplish.
Function cont(requestdate As String) As String
cont = Format(Replace(requestdate, ".", "/"), "'mm_dd_YYYY")
End Function
This code will take a string that Excel does not recognize as a number e.g. 12.12.12 and formats it (about the only useful thing I can think of for this UDF) and return it as a string (that is not a number or date) to a cell that is formatted as text.
You can get as fancy as you like in processing the string entered and formatting the string returned - just that BOTH can never be a number or a date (or anything else Excel recognizes.)
There is no way to do exactly what you're trying to do. I will try to explain why.
You might think that because your function requires a Date argument, that this somehow forces or should force that 12/12/2012 to be treated as a Date. And it is treated as a Date — but only after it's evaluated (only if the evaluated expression cannot be interpreted as a Date, then you will get an error).
Why does Excel evaluate this before the function receives it?
Without requiring string qualifiers, how could the application possibly know what type of data you intended, or whether you intended for that to be evaluated? It could not possibly know, so there would be chaos.
Perhaps this is best illustrated by example. Using your function:
=Cont(1/1/0000) should raise an error.
Or consider a very simple formula:
=1/2
Should this formula return .5 (double) or January 2 (date) or should it return "1/2" (string literal)? Ultimately, it has to do one of these, and do that one thing consistently, and the one thing that Excel will do in this case is to evaluate the expression.
TL;DR
Your problem is that unqualified expression will be evaluated before being passed, and this is done to avoid confusion or ambiguity (per examples).
Here is my method for allowing quick date entry into a User Defined Function without wrapping the date in quotes:
Function cont(requestdate As Double) As Date
cont = CDate((Mid(Application.Caller.Formula, 7, 10)))
End Function
The UDF call lines up with the OP's initial request:
=cont(12/12/2012)
I believe that this method would adapt just fine for the OP's more complex ask, but suggest moving the date to the beginning of the call:
=cont(12/12/2012,a1,b1,c1)
I fully expect that this method can be optimized for both speed and flexibility. Working on a project now that might require me to further dig into the speed piece, but it suits my needs in the meantime. Will update if anything useful turns up.
Brief Explanation
Application.Caller returns a Range containing the cell that called the UDF. (See Caveat #2)
Mid returns part of a string (the formula from the range that called the UDF in this case) starting at the specified character count (7) of the specified length (10).
CDate may not actually be necessary, but forces the value into date format if possible.
Caveats
This does require use of the full dd/mm/yyyy (1/1/2012 would fail) but pleasantly still works with my preferred yyyy/mm/dd format as well as covering some other delimiters. dd-mm-yyyy or dd+mm+yyyy would work, but dd.mm.yyyy will not because excel does not recognize it as a valid number.
Additional work would be necessary for this to function as part of a multi-cell array formula because Application.Caller returns a range containing all of the associated cells in that case.
There is no error handling, and =cont(123) or =cont(derp) (basically anything not dd/mm/yyy) will naturally fail.
Disclaimers
A quick note to the folks who are questioning the wisdom of a UDF here: I've got a big grid of items and their associated tasks. With no arguments, my UDF calculates due dates based on a number of item and task parameters. When the optional date is included, the UDF returns a delta between the actual date and what was calculated. I use this delta to monitor and calibrate my calculated due dates.
All of this can absolutely be performed without the UDF, but bulk entry would be considerably more challenging to say the least.
Removing the need for quotes sets my data entry up such that loading =cont( into the clipboard allows my left hand to F2/ctrl-v/tab while my right hand furiously enters dates on the numpad without need to frequently (and awkwardly) shift left-hand position for a shift+'.