<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In the OGC world, we’ve been trying to make specifications modular for the last few years. This usually means that there is a single core and (potentially) many modules. The modules each depend on the core and there *<b>may</b>* be dependencies on other modules. A developer only has to understand the modules that target a specific application. While it has been/will be hard to retrofit old monolithic standards in some cases, it’s a good structure going forward for allowing application-specific extensions that don’t create any unneeded complexity. It also encourages new ideas and lets survival of the fittest decide which are really good.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I would suggest that we might think of GeoJSON as it exists as a core and the new proposals as modular extensions which can live or dies on their own merits.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>…steve<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></a></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> geojson-bounces@lists.geojson.org [mailto:geojson-bounces@lists.geojson.org] <b>On Behalf Of </b>Matt Priour<br><b>Sent:</b> Monday, October 31, 2011 11:41 AM<br><b>To:</b> Sean Gillies; geojson@lists.geojson.org<br><b>Subject:</b> Re: [Geojson] Toward consensus on proposals<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>I’ll be the first to admit that the Data Series proposal is not fully baked. It was my attempt to simplify a specific but fairly widespread use case. Representing a series of data that is associated with a single feature is excessively onerous and there is not an accepted standardized way to do that in the current GeoJSON spec.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>I was hoping that there would be some discussion of this proposal by those with the most interest in seeing this problem solved. However if the community feels that this is too specific to write into the general GeoJSON spec, then maybe I could write up a separate specification that would be an “official” extension. Maybe something like an Data Series extension to the more general spec would be more acceptable.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>As to the reason the Data Series would be a privileged object and not in the normal properties, that made more sense to me since the data series would likely be tied to a specific feature with its own specific properties that would apply to all the collected data. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>Two things that are most obviously lacking from the data series proposal are<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>1. Multi-dimensional series<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>2. Metadata about the observations (measurement units, full name / label of data property, etc...)<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>Matt Priour<o:p></o:p></span></p></div><div><div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'> <o:p></o:p></span></p></div><div><div><p class=MsoNormal style='background:whitesmoke'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'> <a href="mailto:sean.gillies@gmail.com" title="sean.gillies@gmail.com">Sean Gillies</a> <o:p></o:p></span></p></div><div><p class=MsoNormal style='background:whitesmoke'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>Sent:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'> Monday, October 31, 2011 12:27 PM<o:p></o:p></span></p></div><div><p class=MsoNormal style='background:whitesmoke'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>To:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'> <a href="mailto:geojson@lists.geojson.org" title="geojson@lists.geojson.org">geojson@lists.geojson.org</a> <o:p></o:p></span></p></div><div><p class=MsoNormal style='background:whitesmoke'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>Subject:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'> [Geojson] Toward consensus on proposals<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif";color:black'> <o:p></o:p></span></p></div></div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif";color:black'>Hi all,<br><br>We've got two proposals for changes to the spec and one that may be<br>arriving (Andrew?), so it shouldn't take long to decide whether to<br>accept them or not.<br><br>Circles and Ellipses:<br><a href="https://github.com/GeoJSONWG/geojson-spec/wiki/wiki/Proposal%20Circles%20and%20Ellipses%20Geoms">https://github.com/GeoJSONWG/geojson-spec/wiki/wiki/Proposal%20Circles%20and%20Ellipses%20Geoms</a><br><br>Let's be clear whether we're specifying paths or patches. Center<br>coordinates + radius feels natural to me. If a CRS is defined,<br>wouldn't it be best to apply those units to the radius? Otherwise,<br>could we require units to always (MUST) be meters?<br><br>An ellipse is complicated by the two axes and their orientation.<br>Defining these differently than GML does would need a strong argument.<br><br>Circles and ellipses can be approximated by polygons, but it becomes<br>onerous for good approximations. I'm in favor of this proposal.<br><br>Data Series Proposal:<br><a href="https://github.com/GeoJSONWG/geojson-spec/wiki/Data-Series-Proposal">https://github.com/GeoJSONWG/geojson-spec/wiki/Data-Series-Proposal</a><br><br>I'm concerned about adding something so specialized to the spec and<br>also wonder why a data series object needs to be privileged instead of<br>simply going in the properties object.<br><br>Let's discuss. I'll split the subject in two as soon as it seems needed.<br><br>-- <br>Sean Gillies<br>_______________________________________________<br>Geojson mailing list<br><a href="mailto:Geojson@lists.geojson.org">Geojson@lists.geojson.org</a><br><a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><o:p></o:p></span></p></div></div></div></div></body></html>