Re: GeoJSON

["Mr. Stefan Hagen" <stefan@hagen.link>]

Full disclosure: I am one of the GeoJSON RFC editor's and esp. 
the one, that gently advocated moving that "proven thing" to 
become an IETF RFC so others e.g. OASIS can refer to "it" as 
normative. 

Without any use case in the community, I would have abstained, 
and the reserved keyword via Option 2 would have been good 'nuff 
in my thinking.

Thank you Pat for providing the use case, and based on 

1) this (below) and 

2) my idea (hope), that analysts might exchange converging data with
geometrical confined ever shrinking areas towards (only!) in the end 
and highly significant congruence with regione, a state, or an 
administrative_area would give me confidence, that it is not the 
missing structures in the "protocol" we define, that systematically 
fosters biased (distributed) analysis. (... the attribution aspect 
of IntelData distributed analysis makes me sometimes nervous).

So I suggest we go with Option 1.

All the best,
Stefan.

On 28/06/17 00:17, Patrick Maroney wrote:
> We have an existing well defined/adopted JSON representation for
> GeoLocation data.  There are a variety of Open Source libraries,
> frameworks, et al that can consume, understand, and produce a rich
> representation of GeoLocation attributes.  For example Elastic Stack.  
> 
> Use Case --  We had a recent use case to map the real-time spread of
> WannaCry from both a temporal and GeoLocation perspective.  The ability
> to visualize multiple overlays of geographic regions as a time-series
> map of ISP Endpoints, ASNs, et al, was extremely powerful and provided
> valuable unique insights.  We leveraged the inherent OOTB Elastic Search
> GeoJSON capabilities to quickly develop this time-series Kibana geo
> dashboard. 
> 
> While not specifically in the scope of the CTI TC, the fusion of
> physical to cyber domains is a critical requirement to meet the
> underlying objectives of our endeavors.  For example, the time-series
> mapping of the movement and interactions of terrorist cells in the
> physical domain via cyber based observables (cell phones, Wifi Hotspots,
> Digital Video surveillance, Train/Airline Tickets) is a case in point
> for real-world use cases. Ever increasing Triangulation accuracy within
> polygonal geoloc data is the scenario.
> 
>  Throw in IoT as well.   
> 
> To the extent we can exercise our due diligence (without undue impacts
> to our core mission statements), we should ensure we can integrate and
> fuse with these other Domains.  
> 
> Therefore I advocate for adoption of the full representational
> capabilities of GeoJSON in CTI TC STIX.
> 
> Patrick Maroney
> Principal Engineer - Data Science & Analytics
> Wapack Labs LLC
> pmaroney@wapacklabs.com <mailto:pmaroney@wapacklabs.com>
> (609)841-5104
> 
> 
> On Jun 27, 2017, at 4:45 PM, Wunder, John A. <jwunder@mitre.org
> <mailto:jwunder@mitre.org>> wrote:
> 
> Hey all,
> 
>  
> 
> One of the topics we’ve been talking about for location is the inclusion
> of a field to capture GeoJSON (http://geojson.org/) content. If you’re
> not familiar, GeoJSON is an RFC to capture geographic data structures
> (points, lines, multipoints, multilines, polygons, collections) in JSON.
> 
>  
> 
> Allan Thomson has suggested that we include GeoJSON on the location
> object. We discussed it a bit on the working call today, though, and it
> seemed like nobody had a real need for it…people pretty much just wanted
> the attributes from maxmind (region, country, administrative_area, city,
> street_address, latitude, longitude) and felt that GeoJSON was too much
> at this point. But obviously the TC is bigger than the working call.
> 
>  
> 
> To outline the options:
> 
>  
> 
> Option 1: Include GeoJSON as an optional property alongside the other
> MaxMind-style attributes, including latitude and longitude. This creates
> a bit of “two ways of doing things”, because then you can either use
> GeoJSON to represent a point or you can just use the lat/long fields in
> the core location object.
> 
>  
> 
> Option 2: Defer GeoJSON for now, mark it as a reserved word. This means
> that we have one very straightforward way of representing both addresses
> and lat/lng, but do not have a way to draw other geometries (multiple
> points, lines, bounding boxes, etc).
> 
>  
> 
> Which do people prefer? Do you have a use case for the more feature-rich
> capabilities that GeoJSON provides, or is it sufficient to just stick
> with the MaxMind attributes? If you think we should go with Option 1, do
> you have use cases for the more complicated data structures that you can
> share?
> 
>  
> 
> Consensus from the working call (about 12 people on the call) is that we
> should go with Option 2 and not include GeoJSON at this time.
> 
>  
> 
> Thanks,
> 
> John
>