Yep, have 3-5 secs response time, and get answers with some contents ;-)
Weird thingy.
How did U fix it?
I guess it just knows not to mess with me
Discussion What is the most efficient way to crowdsource the 3D system coordinates
- Thread starter wolverine2710
- Start date
I guess it just knows not to mess with me
I added a date/timestamp submission to my API so you may limit the system data to newer systems. I just added the columns yesterday, so no system is older than a day, right now. Systems created or modified since then get correct timestamps.
Is there any demand for an API to receive distances?
Is there any demand for an API to receive distances?
Yes, I'll want to get distances out.
OK, your wish is my command. Distance API will come ASAP.
In between, can you pls check if the coordinates I found for Col 285 Sector ZN-M b22-2 (-146.03125/33.59375/125.6875) are correct, and calculate the distance to Blende?
In between, can you pls check if the coordinates I found for Col 285 Sector ZN-M b22-2 (-146.03125/33.59375/125.6875) are correct, and calculate the distance to Blende?
Coordinates match. I've got Blende at 340.88. Is it showing as 340.87 in game?
Yes, it shows 340.87 in game. Deng.
For RedWizzard, Finwen and others wanting an API for distances as an alternative to EDSC/TGC, look at my API
You can ask for distances newer than a specific date/time: http://the-temple.de/public/distances.php?startdatetime=2015-05-18 07:00 (everything younger than today 7:00 GMT, f.ex.)
You can ask for distances newer than a specific date/time: http://the-temple.de/public/distances.php?startdatetime=2015-05-18 07:00 (everything younger than today 7:00 GMT, f.ex.)
Last edited:
I noticed Finwen is using an ID in his database to remember the last fetched systems and distances. Would it be useful if you could receive the ID from my API and ask for systems or distances beginning at a specific ID instead of a date and time?
I did lot's of things at the API in the past few days, and anyone who submits data to TGC may submit them to my site, additionally. Right now I'm testing some things, and to help me you may submit the distance data to http://the-temple.de/public/posttest.php. This page is NOT MEANT to enter distances by hand, it is an API. Data format is the same as EDSC/TGC, only difference is to use the method GET instead of POST.
I did lot's of things at the API in the past few days, and anyone who submits data to TGC may submit them to my site, additionally. Right now I'm testing some things, and to help me you may submit the distance data to http://the-temple.de/public/posttest.php. This page is NOT MEANT to enter distances by hand, it is an API. Data format is the same as EDSC/TGC, only difference is to use the method GET instead of POST.
I'd say that all changes since a given timestamp are what you want. That way you get, and should be handling, changes to existing data as well as purely new data. I did specifically code the data puller for my route planner DB to work in this way for EDSC.
As much as we know it'll end up being a week or more of back and forth I think perhaps the useful thing to do at this point is take a step back to identify the actual uses cases, the problems with EDSC, and additional functionality that people know they'd be using and ensure any EDSC replacement addresses all of that.
Oh I don't want to remove the date/time filter, I wanted to make the ID thing availabe additionally. But after thinking a bit it doesn't make really much sense, since a system or a distance with a certain ID may change after creation, so everything after a given date & time is way more interesting.
It's not much work to include it in my API, but if it is useless and no one wants it, I have better things to do in my spare time
It's not much work to include it in my API, but if it is useless and no one wants it, I have better things to do in my spare time
My point is more that anyone thinking the "get by ID" is useful is probably going to write code that doesn't take into account the possibility of changes to data. Better to force them to think about that IMO (as I had to with using EDSC). I'd compare it to how PHP used to have register_globals default to on .
.Oh I don't want to remove the date/time filter, I wanted to make the ID thing availabe additionally. But after thinking a bit it doesn't make really much sense, since a system or a distance with a certain ID may change after creation, so everything after a given date & time is way more interesting.
It's not much work to include it in my API, but if it is useless and no one wants it, I have better things to do in my spare time
I'd actually prefer an incrementing "change number". I wouldn't use static IDs on the distances and systems - I've built everything using the system names as a unique key. But a simple sequentially incrementing "last change number" would be a good alternative to using a timestamp. The problem with timestamps is dealing with timezones. If you're using timestamps please make sure they're treated as UTC and not local time.
This might be a good idea, depending on exact implementation there's an edge case with multiple updates to the same data in the same second. However the easiest way to solve that is to be paranoid and request all changes including the timestamp of the previous last change you saw, i.e. request and cope with overlap. If last seen change was 2015-05-21T034536Z then either the API always includes the second you specify for "changes since this timestamp" or you specify 1 second earlier, i.e. 2015-05-21T034535Z. Also, would this be a global 'change number' across the entire data set? If so that means having to deal with multiple simultaenous updaters. If not then I'm not sure how you use those tuple change numbers to request ALL changes since a previous pull.
Basically I'd keep using second resolution timestamps for this and make sure you overlap so as to not miss the edge case.
That strikes me as exactly the wrong way to do it. ALWAYS use a unique static ID on a data tuple. Anything else that is actual data is subject to change. We know FD have changed/corrected some system names since release and there's nothing to say they won't eventually rename some of the PG names to a more human monicker. Either way you have to deal with merging data from the different names, but using a unique ID means that the name is the only thing you need to change, not also anything that was referring to the system. Remember there may be any number of other programs making use of the data. Think of a simple Explorer Notes app that allows a player to makes notes about the system, you'd want those tied to a unique, never changing, ID for the system, not a name that you may then have to search/replace in the application data due to a rename.
Which means timestamps aren't an issue at all. For my own projects I have the DB specified as using UTC, set "TZ=UTC" in all programs/scripts, and if interfacing to something else that doesn't do that I'll convert back and forth as needed. Using UTC for any timestamp is the only sane thing. The only time to use anything other than UTC is user input and display to the user.
I'm not going to go through all 75 pages of posts to find a particular answer, and I've used the search facility without any joy.
I like to trilaterate systems using Finwen's entry page, and also add distances to some uncalculated systems to add to the pool.
Once an uncalculated system has a critical number of reliable measurements from trilaterated systems, does the database perform the calculation and determine the location of the uncalculated system?
I'm thinking there are some systems that are WAY beyond the ability to reach with FSD, but would make good markers to trilaterate against.
I like to trilaterate systems using Finwen's entry page, and also add distances to some uncalculated systems to add to the pool.
Once an uncalculated system has a critical number of reliable measurements from trilaterated systems, does the database perform the calculation and determine the location of the uncalculated system?
I'm thinking there are some systems that are WAY beyond the ability to reach with FSD, but would make good markers to trilaterate against.
That's a good point. I admit that I didn't take a close look at timezones until now - I thought "PHP & MySQL will do that stuff"...
Now I did. The date & time when the last update of a system or distance happened was stored without timezone data. Now it is. All dates & times are stored in UTC, that's good. The API accepts every date & time format MySQL is able to understand. Bad thing: The API gives all date/time data converted to the server's timezone (because the scripts are running there), and that's GMT+2 (Europe/Berlin, CEST). I'll fix that, soon. I think the API sould format everything in GMT, for this is a global notation which every 3rd party tool should understand.
For user output from the web FE it would be nice to know the user's timezone and have everything converted. This is cosmetics, so not at high prio. I'm not sure how to get the TZ. I could generate a list of available timezones and let registeres users choose & save their preferred timezone. This list has 1781 entries. I didn't know there are this many timezones... Maybe I'll do some little Javascript to read the client's (webbrowser's) time and use it as TZ info.
Now I did. The date & time when the last update of a system or distance happened was stored without timezone data. Now it is. All dates & times are stored in UTC, that's good. The API accepts every date & time format MySQL is able to understand. Bad thing: The API gives all date/time data converted to the server's timezone (because the scripts are running there), and that's GMT+2 (Europe/Berlin, CEST). I'll fix that, soon. I think the API sould format everything in GMT, for this is a global notation which every 3rd party tool should understand.
For user output from the web FE it would be nice to know the user's timezone and have everything converted. This is cosmetics, so not at high prio. I'm not sure how to get the TZ. I could generate a list of available timezones and let registeres users choose & save their preferred timezone. This list has 1781 entries. I didn't know there are this many timezones... Maybe I'll do some little Javascript to read the client's (webbrowser's) time and use it as TZ info.
In most cases, yes it does. In some cases it doesn't. It's unsure why this happens, there are several possible reasons. We got no sign of life from TornSoul since mid of December, so it's only speculation. But don't worry, your work is not lost. RedWizzard & me are copying EDSC/TGC data, and we're investigating "problem systems". In the near future there will be an EDDiscovery version and a modified JS from RedWizzard which will transfer new distances to EDSC and to my site, too. We will probably replace EDSC.
UTC timestamps are pretty much standard practice, and how EDDN implements them.