OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [External] [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


So what is the problem this would actually solve? I understand the use case of specifying a human-readable location (“Dallas, Texas, USA”, “1600 Pennsylvania Ave, Washington, DC”, etc.) but I don’t quite understand what lat/long is used for in this context.

 

From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Tuesday, July 18, 2017 at 9:51 PM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [External] [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision

 

Since we do not yet really know what we need here, I would propose that we add this field at a later time. I fully understand the problem we think we are trying to solve, but I am not sure we have identified the best solution. It would be nice if we had a bunch of real-world problems in products that were driving this.

 

Further, if you are uncertain about a location you should NOT be using lat/long to represent the location. You should be using one of the other properties like region, country, city, administrative_area, etc. Those are the named non-precise ways of doing location.

 

Bret 

Sent from my iPhone


On Jul 18, 2017, at 11:33 PM, Wunder, John A. <jwunder@mitre.org> wrote:

Hey everyone,

 

We’ve been having a conversation about the best way to represent the precision of a given latitude and longitude pair. What I mean by that is, if I give you 45.234234 latitude by 45.2342 longitude (literally just typed random numbers there) is that describing an exact point, just pointing to a city center, or even just pointing to a country?

 

We have a couple options here:

 

  1. Just define in normative text that, for STIX, latitude and longitude is approximate. This would mean that you couldn’t really rely on it to be accurate to an address, even in cases where it was.
  2. Have an optional property to represent the precision. If the property is present, it describes the precision in terms of meters. If absent, we have two options:
    1. Precision is unspecified, and consumers can take that however they want
    2. Default precision to perhaps 10km (roughly a zip code), so consumers can pretend the value was that
  1. Have a required precision property

 

We also talked about significant digits but due to the ways JSON parsers read data it would mean using a string and likely that data would also be lost in those cases too (and even if there it’s harder to get to). It didn’t seem like a great option compared to any of the above, but maybe we’re missing something.

 

So, what do people think? Any other arguments for one or the other?

 

I don’t have any strong opinions really other than that #3 is probably not workable (producers would just make up a value in a lot of cases).

 

John

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]