Open martinhannigan opened 2 months ago
IXes don't have an address. Hence, geocode is meaninless. -1
If an IX has a presence in a facility that does have a geocode which clearly signals the physical location of the IX.
Since it’s for the export function data, can you explain how this is harmful or incorrect? Seems like a data and competition improvement to me.
Tks!
On Sun, Feb 25, 2024 at 12:25 Arnold Nipper @.***> wrote:
IXes don't have an address. Hence, geocode is meaninless. -1
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1556#issuecomment-1963006348, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQXELBOPOGASIMN7DETYVNX2FAVCNFSM6AAAAABDXI7DDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRTGAYDMMZUHA . You are receiving this because you authored the thread.Message ID: @.***>
I have no problem adding all the geocodes of the facilities where the IX has a presence. We could even add a read-only field to the ix
object which would be an array of geocodes.
PC call: has come up before, return array of geocodes where present?
What issue has this come up in before?
We need to be careful to design for the masses vs the elite which is why feature parity is important.
On Thu, Mar 14, 2024 at 13:05 Jack Carrozzo @.***> wrote:
PC call: has come up before, return array of geocodes where present?
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1556#issuecomment-1997933104, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQT5CATQSSN7DNB7I5DYYHKE5AVCNFSM6AAAAABDXI7DDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXHEZTGMJQGQ . You are receiving this because you authored the thread.Message ID: @.***>
What issue has this come up in before?
I've already proposed a solution. This would be adding a field geocode
to ix
. This read-only field would be an array containing the geocodes of the facilities where the IX offers its services. Maybe an array of triples (fac.name, latitude, longitude) would even make more sense.
Interesting. That might work. How do you suggest we test it to see?
The geo code is good for Google Earth, but also other tools like ArcGIS. KML/KMZ transports VERY poorly between apps which is another reason for export flexibility.
On Thu, Mar 14, 2024 at 17:17 Arnold Nipper @.***> wrote:
What issue has this come up in before?
I've already proposed a solution. This would be adding a field geocode to ix. This read-only field would be an array containing the geocodes of the facilities where the IX offers its services. Maybe an array of triples ( fac.name, latitude, longitude) would even make more sense.
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1556#issuecomment-1998498489, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQXEG6NCJHT65MH3EEDYYIHXHAVCNFSM6AAAAABDXI7DDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJYGQ4TQNBYHE . You are receiving this because you authored the thread.Message ID: @.***>
Is your feature request related to a problem? Please describe.
It's not a problem more than a major improvement.
What is the impact?
Leaps forward for research and interconnection.
Are there security concerns?
No.
Are there privacy concerns?
No, you need to be found to connect.
Describe the solution you'd like
Add geocodes for IX objects search results and export function using FAC object affiliation for geocode source.
Do you think this feature will require a formal design? yes/no (add why if no)
Perhaps
Describe alternatives you've considered
There are no alternatives.
Could this feature request need support from the Admin Committee?
No.
What is the proposed priority?
High. There have been requests for similar data and its a high value feature.