Station Lat Long not matching Map Position

I’m developing a section plot and testing it out with local Shakes.

Apart from the usual development issues to solve, I’ve found what looks like a significant error in the metadata position for shake R811A compared to it’s indicated position on the map.

Here’s the map showing the indicated position of R811A (circled).

And this is the stations and their lat longs that I’m developing/testing with.
image

If the indicated position is right it should be more like -32.6 149.5.

I know the meta data is modified a little bit to protect the accurate position of the station from undesirables, but this seems too much. I don’t own the station so I don’t know it’s true position, but I suspect the indicated position is more likely to be correct. Perhaps worth checking with the station owner.

Al.

1 Like

Hello Sheeny,

From what I can see, the last open epoch for that particular Shake indicates the following coordinates:

<latitude>-32.62162162</latitude>
<longitude>149.4946257</longitude>

Which, in my opinion, reflects what is shown on the map at this point in time. What has likely happened is that the station was previously located in another town/city, and it was then moved to its current position.

Looking forward to your section plot!

Thanks Stormchaser.

That’s weird. I wonder why my code is picking up a wrong lat, long? There’s about a 200km difference in position - that’s how I found it. Hmmm…

I am wrestling with the code for the section plot a bit. I’ve got some weird things happening like traces not demeaning properly when combined into a stream, so this just fits right in to weirdness of the project! ;o)

I’ve had other code open in Spyder when I’ve been testing it, so I might make sure I have nothing else open next time I run it just to make sure python is not mixing variables or something silly like that.

I look forward to completing the section plot too (I might be back in another thread for help yet!)

Al.

2 Likes

Here’s the code that’s calling the station metadata. I’m now not sure it’s correct. I think it’s picking up the first station code data not the last. The metadata in XML format shows all are restrictedStatus=“open”. I added a test point at the end of this block of code “print(sta)” to show the metadata downloaded.


        inv = rs.get_stations(network='AM', station=slist[i], level='RESP')  # get the instrument response
        sta = inv[0][0]         #station metadata
        latS = sta.latitude     #station latitude
        lonS = sta.longitude     #station longitude
        #eleS = sta.elevation     #station elevation
        print(slist[i], latS, lonS)
        print(sta)

The result of the test point are:

I believe this shows the FIRST open epoch for each shake. The data for R21C0 (my shake) shows it’s first epoch as below:

The current epoch is:

Note there is no endDate in the current epoch.

Now my station R21C0 has 3 epochs in the metadata file so I tried inv[0][2] and got my latest epoch. This also happened to give me the latest epoch for R811A by fluke, but I noticed not for one other shake in my list.

How do I change my code to pick up the LAST open epoch?

Thanks,

Al.

2 Likes

OK, I’ve come up with a solution, but if anyone knows a simpler or better way, I’d appreciate them sharing.
This is the code I’ve come up with to get the latest epoch data in the inventory:


inv = rs.get_stations(network='AM', station=slist[i], level='RESP')  # get the instrument response
        #print(inv[0])
        k=0
        while True:
            sta = inv[0][k]         #station metadata
            staOK = sta.is_active(time=eventTime)
            if staOK:
                break
            k += 1
        latS = sta.latitude     #station latitude
        lonS = sta.longitude     #station longitude
        #eleS = sta.elevation     #station elevation
        print(slist[i], latS, lonS)
        print(sta)

So I’ve set up a loop to test every epoch until it find the one that’s active at the eventTime. This should also handle retrospective events when an old epoch is relevant I think.

Al.

2 Likes

Hello Al,

My first thought would have been to take the current date, compare it to the ones listed in the inventory file, and then select the closest epoch. However, I think that your approach could be faster and easier to implement.

Thank you as usual for sharing your code with the community! If something else comes to mind I will edit this message with it.

1 Like