[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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: 1.
Lat/long (required) 2.
Precision (optional, defaults to 0)
a.
Alternatively we could just not have this field, and potentially add it in a later release 3.
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> 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]