[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
I also do not get, why GeoJSON should "clearly" lack anything substantial here and fear the complexity pushed out of our "standardization process" will come back as even more problematic complexity for implementers and users later. No "rolling it the STIX way" convinces me (yet). Until now the mails on this list and in that regard to me mostly read like: "they [GeoJSON] do not this and they do not offer that". Maybe there is a reason? There have been discussions - when after years of successful practice that working community standard went IETF to later become RFC 7946, and most "uncertain" requirements requested by one group lead to opposition of well people seeing this definitively different (the uncertain stuff they found important). Thus the consensus of the "internet" community found a minimal general statement: As in [RFC5870], the number of digits of the values in coordinate positions MUST NOT be interpreted as an indication to the level of uncertainty. Noted at https://tools.ietf.org/html/rfc7946#section-3.1.10 and https://tools.ietf.org/html/rfc5870#section-3.4.3. (As John was so gentle to offer to this list). Adding 3 offerings (I personally "like") to the below referenced list Jason was so kind to point to (dated from 18 October 2013): * GitHub offers great support for GeoJSON out of the box. Cf. e.g. https://help.github.com/articles/mapping-geojson-files-on-github/ * Google Maps directly supports GeoJSON: Cf. eg. https://developers.google.com/maps/documentation/javascript/datalayer#load_geojson * GeoJSON.io (https://github.com/mapbox/geojson.io) We can talk about complexity, but we should not enforce complexity on the users of the specification or the implementers of conforming tools I think. All the best, Stefan. On 19/07/17 20:12, Jason Keirstead wrote: > I have to disagree RE "implementation complexity". > > Either way it is a couple of dozen bytes of JSON. > > If anything, "rolling our own" is dramatically increasing our complexity > because it means now I can no longer use a prepared library or feed it > into any third party product (ref: http://wiki.geojson.org/Users) > > > - > Jason Keirstead > STSM, Product Architect, Security Intelligence, IBM Security Systems > www.ibm.com/security > > Without data, all you are is just another person with an opinion - Unknown > > > > > From: "Wunder, John A." <jwunder@mitre.org> > To: "Struse, Richard J." <rjs@mitre.org>, Jason Keirstead > <Jason.Keirstead@ca.ibm.com> > Cc: Bret Jordan <Bret_Jordan@symantec.com>, > "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Mark > Davidson <Mark.Davidson@nc4.com>, "Trey Darley" <trey@newcontext.com> > Date: 07/19/2017 11:43 AM > Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, > latitude/longitude, and precision > ------------------------------------------------------------------------ > > > > Yeah I agree with Rich here, GeoJSON is far beyond a lat/lng with > precision. In fact, looking through the GeoJSON specification, they > don’t even include anything to indicate precision or uncertainty. > > *From: *"Struse, Richard J." <rjs@mitre.org>* > Date: *Wednesday, July 19, 2017 at 10:36 AM* > To: *Jason Keirstead <Jason.Keirstead@ca.ibm.com>* > Cc: *"Bret Jordan (CS)" <Bret_Jordan@symantec.com>, > "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, John > Wunder <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey > Darley <trey@newcontext.com>* > Subject: *Re: [cti-stix] Re: [EXT] [cti-stix] Location, > latitude/longitude, and precision > > In all fairness, GeoJSON is a big lift in terms of implementation > complexity and isn’t really comparable to one additional precision property. > > Given that, how would you respond to John’s original question regarding > precision? > > *From: *<cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead > <Jason.Keirstead@ca.ibm.com>* > Date: *Wednesday, July 19, 2017 at 10:32 AM* > To: *Richard Struse <rjs@mitre.org>* > Cc: *Bret Jordan <Bret_Jordan@symantec.com>, > "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, > "Wunder, John A." <jwunder@mitre.org>, Mark Davidson > <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>* > Subject: *Re: [cti-stix] Re: [EXT] [cti-stix] Location, > latitude/longitude, and precision > > As I stated a few days ago - if we are going to start including > precision then I would rather we just go back to GeoJSON which is an > existing RFC supported out of the box by many products. > > Folks pressed to not use GeoJSON because they would not use all the > features, and now we're talking about re-inventing things it already > gives us. > > - > Jason Keirstead > STSM, Product Architect, Security Intelligence, IBM Security Systems_ > __www.ibm.com/security_ > > Without data, all you are is just another person with an opinion - Unknown > > > > > From: "Struse, Richard J." <rjs@mitre.org> > To: Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley > <trey@newcontext.com> > Cc: "Wunder, John A." <jwunder@mitre.org>, Mark Davidson > <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org" > <cti-stix@lists.oasis-open.org> > Date: 07/19/2017 11:02 AM > Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, > latitude/longitude, and precision > Sent by: <cti-stix@lists.oasis-open.org> > ------------------------------------------------------------------------ > > > > > Your opinion is noted. What do others on the list think? > > On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote: > > I disagree > Bret > > > Sent from my iPhone > > > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote: > > > >> On 19.07.2017 12:47:55, Struse, Richard J. wrote: > >> 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. > >> > > > > Thanks, Rich. > > > > I think this is the correct approach. > > > > -- > > Cheers, > > Trey > > > ++--------------------------------------------------------------------------++ > > Director of Standards Development, New Context > > gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 > > > ++--------------------------------------------------------------------------++ > > -- > > "No matter how hard you try, you can't make a baby in much less than 9 > > months. Trying to speed this up *might* make it slower, but it won't > > make it happen any quicker." --RFC 1925 > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]