Discussion What is the most efficient way to crowdsource the 3D system coordinates

[TornSoul]

Up to now I was thinking that if there was more than one "perfect match" (as per reverse distance checking) then RMS should be able to pick (correctly) among them (as RMS really just is a delta-distance measure, exaggerating those that are higher).

But the example I posted disprove that (ie. RMS picks the wrong one).

So... If there's more than one "perfect match", it simply means we need more distances before a candidate is selected as the "correct one".

 

[Biteketkergetek]

Up to now I was thinking that if there was more than one "perfect match" (as per reverse distance checking) then RMS should be able to pick (correctly) among them (as RMS really just is a delta-distance measure, exaggerating those that are higher).

But the example I posted disprove that (ie. RMS picks the wrong one).

So... If there's more than one "perfect match", it simply means we need more distances before a candidate is selected as the "correct one".

Exactly. In this specific case the RMS idea might be failing because for these set of coordinates all of the input have increased or left intact (two values ending in 0 unchanged, two other with 8 at the end, and one with 6 in the end rounded up). IOW the average distance calculated with 2dp and 3dp is farther apart than usual. I say we're lucky we had one of those. Sorry if I've pointed that out earlier, I seem have problems with the forum engine this evening...

 

[Harbinger]

I personally reverse check the distances for all reference stars used in my solution but I've found that with 2 decimal place precision using 9 reference stars as I used to some (not all) of the reverse distance checks were coming back with up to +/-0.005 LY variances. I now use 15 reference stars which results in 1365 permutations of 4 star groupings (no repetition with changed order). I haven't had a failure to find a set of coordinates that all reverse checks agree on since adding more reference stars. More is definitely better.

NOTE: 10-11 reference systems were usually enough but for the sake of an extra 60 seconds I thought I may as well go for 15.

@smacker: I've been thinking about the bases situation and I've made some updates:

Spoiler

    {
        "name": "Aulin",
        "contributor": "FD",
        "x": -19.6875,
        "y": 32.6875,
        "z": 4.75,
        "region": "Premium Beta2",
        "contributed": "2014-10-21T17:16:31.000Z",
        "stations": [
            {
                "station": "Yurchikhin Gateway",
                "distance": 60.2,
                "type": "Scientific Outpost",
                "commodities_market": false,
                "black_market": false,
                "shipyard": false,
                "outfitting": false
            },
            {
                "station": "Aulin Enterprise",
                "distance": 117,
                "type": "Orbis Starport",
                "commodities_market": true,
                "black_market": false,
                "shipyard": true,
                "outfitting": true
            },
            {
                "station": "Binnie City",
                "distance": 347,
                "type": "Scientific Outpost",
                "commodities_market": false,
                "black_market": false,
                "shipyard": false,
                "outfitting": false
            }
        ]
    }

As you can see I now include the station type, whether or not the station has a commodities market, black market, shipyard or outfitting which should be useful if people only want to grab certain bases for example only those with a commodities market. As this requires physically visiting the bases to get the information there are many from my previous additions currently listed as "unknown". I'll try and at the very least get the rest of these checked ASAP and any future ones I add will have this information in full.

 

[Biteketkergetek]

@smacker: I've been thinking about the bases situation and I've made some updates:

Spoiler

    {
        "name": "Aulin",
        "contributor": "FD",
        "x": -19.6875,
        "y": 32.6875,
        "z": 4.75,
        "region": "Premium Beta2",
        "contributed": "2014-10-21T17:16:31.000Z",
        "stations": [
            {
                "station": "Yurchikhin Gateway",
                "distance": 60.2,
                "type": "Scientific Outpost",
                "commodities_market": false,
                "black_market": false,
                "shipyard": false,
                "outfitting": false
            },
            {
                "station": "Aulin Enterprise",
                "distance": 117,
                "type": "Orbis Starport",
                "commodities_market": true,
                "black_market": false,
                "shipyard": true,
                "outfitting": true
            },
            {
                "station": "Binnie City",
                "distance": 347,
                "type": "Scientific Outpost",
                "commodities_market": false,
                "black_market": false,
                "shipyard": false,
                "outfitting": false
            }
        ]
    }

Interesting. This structure perfectly matches mine. See here. (In go structure members have a so called structure tag in additon to name and type, which is an optional string. So the text after 'json:' will be used to import/export elements of the Station struct). I just omitted the _ from the commodity- and black market and have "dist" instead of "distance" (this latter might be an oversight, I apparently forgot to spell the full name). Was it always "commodities market" and not "commodity market" in ED? I don't know how I've got the latter instead.

 

[Harbinger]

Was it always "commodities market" and not "commodity market" in ED? I don't know how I've got the latter instead.

I assume so, commodities is plural whereby commodity is singular and would imply that there is only 1 item available.

 

[JesusFreke]

... This listing must take the 2dp precision into account, therefore the tool should ask for a distance from a system where this 2dp distance would be enough to make a decision. It may also happen that no such system known to us exist yet. This idea could be tested by generating distances from additional systems (since we already know the correct beta2 coordinate, which is -9.46875, 17.8125, 30.4375 according to all tools including mine, if 3dp precision input is used).

Exactly! This is what the newest version of my tool (that I posted on friday) does to determine the next reference star to ask for. I haven't used it much yet, but in the few cases I've tried, it worked quite well. In the example "session" I had posted, for example, it had found a total of 7 candidate positions for a star, and then found (at least) 1 reference star that had a different 2dp rounded distance to each of the 7 candidate positions, so that knowing that distance was guaranteed to eliminate all but 1 of the candidates.

 

[RedWizzard]

Updating to your latest version.

I just noticed, you should remove all the previous measurements to Fu Haiting. The position of this star changed between Beta 2 and Beta 3.

Right. I meant to do that when I imported the beta 3 data but the code to flag the bad distances must've had a bug as nothing got flagged and then I forgot about it.

As well as Fu Haiting there were a handful of distances to Baga and Chapoyo that are also invalid. I've removed them all now.

 

[Snuble]

The system data should be expanded to include the fields allegiance, economy, government, population and security. Thats most likely the data we will need regarding systems. Unvisited systems that do no offer any data for those fields should be regarded as Unknown.

For bases, there also need to be a field that stores what ships sizes a dock can take. I've just run into a dock at FN Virginis that did not let my Lakon 6 land. This is data that will be important when we start trading. Or just want the closest system that can refuel and restock that Anaconda...

 

[RedWizzard]

You're probably better off using RedWizzard's latest systems.json from his Github as your primary source of data. He's imported my stations list into it now. In fact I've changed the systems.json file I'm sharing to only include modifications I've made recently to make it easier for RedWizzard. Once I notice RedWizzard has imported them I'll update my shared file as appropriate.

You can of course keep monitoring my shared file to grab data as and when it becomes available.

If you're only including changes you'll need some way of indicating when a system should be deleted. Probably easiest to change the region to 'delete' or something like that.

I've just imported your latest batch of updates so my systems.json should be up to date. The only change I didn't bring across was the region change for G 205-38. You've marked it as "outside Beta3" but it's only got 4 distances so I think it's position is still not verified.

 

[clinton]

Could someone confirm that the latest system coords are returned by this jsfiddle here: http://jsfiddle.net/7g064mr3/ or are they Beta 2 coordinates? If so can I ask where the Beta 3 ones are?

 

[Snuble]

Just found another system with economy that where not in Beta 3 coord from FD. Wolf 359, Industrial, 129999 souls, 3.896:6.48:-1.91 (not snapped to grid) "Edit: corrected X"

 

[Biteketkergetek]

I assume so, commodities is plural whereby commodity is singular and would imply that there is only 1 item available.

The wikipedia article should be corrected then. This may be a British/American thing then.

- - - - - Additional Content Posted / Auto Merge - - - - -

Could someone confirm that the latest system coords are returned by this jsfiddle here: http://jsfiddle.net/7g064mr3/ or are they Beta 2 coordinates? If so can I ask where the Beta 3 ones are?

See here.

 

[maddavo]

Just found another system with economy that where not in Beta 3 coord from FD. Wolf 359, Industrial, 129999 souls, 3.896:6.48:-1.91 (not snapped to grid) "Edit: corrected X"

Wolf 359 was in the FD B3 list. 'Wolf 359' 3.875 6.46875 -1.90625 'Beta3'

- - - - - Additional Content Posted / Auto Merge - - - - -

What do we do with new systems when we work out their coords? Do we post here or is there a database to upload them to or do we send to RedWizzard to incorporate into system.json? I have 26 systems I found this afternoon.

 

[wolverine2710]

Wolf 359 was in the FD B3 list. 'Wolf 359' 3.875 6.46875 -1.90625 'Beta3'

- - - - - Additional Content Posted / Auto Merge - - - - -

What do we do with new systems when we work out their coords? Do we post here or is there a database to upload them to or do we send to RedWizzard to incorporate into system.json? I have 26 systems I found this afternoon.

So far it worked like this. Post your distances and optional calculated coordinates here. If using one of the many tools from the OP (higly preferred) you can submit coords to. RW most of the time at the end of the day tries to verify them and create a new TOR systems.json file. TOR is The One Refernce. Work is ongoing by TornSouls for TGR. This makes uploading distances/coords easy and the tools can use TGR to indicate to a user that a system has been done before. Hope this helps a bit.

 

[RedWizzard]

Could someone confirm that the latest system coords are returned by this jsfiddle here: http://jsfiddle.net/7g064mr3/ or are they Beta 2 coordinates? If so can I ask where the Beta 3 ones are?

Those are beta 2 coordinates. Probably the most up to date list of systems for beta 3 is my systems.json.

 

[Biteketkergetek]

I personally reverse check the distances for all reference stars used in my solution but I've found that with 2 decimal place precision using 9 reference stars as I used to some (not all) of the reverse distance checks were coming back with up to +/-0.005 LY variances. I now use 15 reference stars which results in 1365 permutations of 4 star groupings (no repetition with changed order). I haven't had a failure to find a set of coordinates that all reverse checks agree on since adding more reference stars. More is definitely better.

NOTE: 10-11 reference systems were usually enough but for the sake of an extra 60 seconds I thought I may as well go for 15.

@smacker: I've been thinking about the bases situation and I've made some updates:

Spoiler

    {
        "name": "Aulin",
        "contributor": "FD",
        "x": -19.6875,
        "y": 32.6875,
        "z": 4.75,
        "region": "Premium Beta2",
        "contributed": "2014-10-21T17:16:31.000Z",
        "stations": [
            {
                "station": "Yurchikhin Gateway",
                "distance": 60.2,
                "type": "Scientific Outpost",
                "commodities_market": false,
                "black_market": false,
                "shipyard": false,
                "outfitting": false
            },
            {
                "station": "Aulin Enterprise",
                "distance": 117,
                "type": "Orbis Starport",
                "commodities_market": true,
                "black_market": false,
                "shipyard": true,
                "outfitting": true
            },
            {
                "station": "Binnie City",
                "distance": 347,
                "type": "Scientific Outpost",
                "commodities_market": false,
                "black_market": false,
                "shipyard": false,
                "outfitting": false
            }
        ]
    }

As you can see I now include the station type, whether or not the station has a commodities market, black market, shipyard or outfitting which should be useful if people only want to grab certain bases for example only those with a commodities market. As this requires physically visiting the bases to get the information there are many from my previous additions currently listed as "unknown". I'll try and at the very least get the rest of these checked ASAP and any future ones I add will have this information in full.

Suggestion: as I understand value null in JSON usually means that the value missing. Therefore I think null would be much better for the new boolean fields instead of "unknown".

I mean at least for "shipyard", "outfitting", "commodities_market" and "black_market", for others like "type" the existing "unknown" might work.

 

[RedWizzard]

Suggestion: as I understand value null in JSON usually means that the value missing. Therefore I think null would be much better for the new boolean fields instead of "unknown".

I mean at least for "shipyard", "outfitting", "commodities_market" and "black_market", for others like "type" the existing "unknown" might work.

Alternatively we could just leave those fields out entirely when we don't have data for them.

 

[Michael Brookes]

System names should be unique - if they aren't then raise a ticket.

Michael

 

[Biteketkergetek]

Alternatively we could just leave those fields out entirely when we don't have data for them.

That is what I do all the time, but keeping them is also understandable. It may be useful if the json is manually edited, just search for null to see what needs to be filled in, and it's easier to just replace the null, rather than having to type the field name too.

 

[gazelle]

System names should be unique - if they aren't then raise a ticket.

Done for:

Chara	49854.53	40963.25	23980.19
Chara	49980.16	41011.66	24100.22

Naraka	49950.91	41011.22	24099.47
Naraka	50069.81	41117.19	24174.59

This are actually the two "nameless" systems in the list provided by you (Michael Brookes).