I’ve come to believe that precision should be optional. The purist in me wants the text to say that if precision is omitted, the precision of the lat/long is unspecified. But I’m willing to live with text
that says if precision is unspecified, it defaults to 10km as John-Mark originally proposed.
From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Wednesday, July 19, 2017 at 8:32 AM
To: Mark Davidson <Mark.Davidson@nc4.com>, Bret Jordan <Bret_Jordan@symantec.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
One quick note about our current Location SDO is that lat/lng are not required. You can say “US” or “Washington, DC, US” without giving a lat/lng, for example. Precision describes specifically precision of
lat/lng, though.
I’m also not sure how realistic a precision of 0 is. Even an address isn’t really precise to 0 meters, and this would mean that producers who can’t be bothered to populate precision are by default saying their
lat/lng is super precise, which is probably not accurate. If we do have optional with a default, I’d suggest we go with what New Context came up with (10km) in the absence of other compelling reasons.
John
From: Mark Davidson <Mark.Davidson@nc4.com>
Date: Wednesday, July 19, 2017 at 7:59 AM
To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, John Wunder <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Products are going to visually represent this information to users, so we need some concrete information around it.
Here are some examples, which are rental listings on HomeAway.com for a non-CTI example. (They are Portland, ME, not Portland, OR)
In a product, visually, an “imprecise” location is reasonable to represent as a circle (e.g., lat/long + precision):
Whereas a “precise” location could use a pin
As a potential consumer of this information, I would go for:
- Lat/long (required)
- Precision (optional, defaults to 0)
- Alternatively we could just not have this field, and potentially add it in a later release
- Alternatively we could just not have this field, and potentially add it in a later release
- Some text describing that lat/long + precision define a geometric shape (e.g., a circle) that includes the location. This not only accounts for imprecision
in the source data, it enables the use case where somebody doesn’t want to be as specific as they could be. Maybe higher $$$ data sets are more precise.
When I think of Soltra’s use cases for location, it is displaying the information on screen for users, workflows (e.g., auto-route anything in APAC to team XYZ), and enrichment. The fields I list above support
all those. Anything that’s crazy big (e.g., lat/long, precision=1 AU) could get kicked out to a human for categorization or rejection.
Producers of CTI can weigh in on how useful the location property is or would be.
Thank you.
-Mark
From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, July 19, 2017 at 12:51 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [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:
- 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.
- 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:
- Precision is unspecified, and consumers can take that however they want
- Default precision to perhaps 10km (roughly a zip code), so consumers can pretend the value was that
- 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
Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure
under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received
this communication in error, please notify the sender and destroy and delete any copies you may have received.