<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">absolutely so! If you want to access data items as a whole piece, and the item fits through the pipe conveniently then I am fully on board. However, sometimes we want to get pieces
that fit the pipe (and convenient for us to chew), and we want something to be done - my favorite example on remote sensing imagery is the vegetation index. Or even a histogram: my fav here is CSV, or JSON, or... but not to download a NetCDF file. So, as so
often: it depends.<br>
<div><br>
cheers,<br>
Peter<br>
<br>
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<div style="font-family:Tahoma; font-size:13px">
<p><font face="Times New Roman">-- <br>
Dr. Peter Baumann- Professor of Computer Science, Jacobs University Bremen<br>
http://www.faculty.jacobs-university.de/pbaumann<br>
mail: p.baumann@jacobs-university.detel: +49-421-200-3178, fax: +49-421-200-493178<br>
- Executive Director, rasdaman GmbH Bremen (HRB 26793)http://www.rasdaman.com,<br>
mail: baumann@rasdaman.com<br>
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882<br>
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)<br>
<br>
<br>
</font></p>
<p><br>
</p>
</div>
</div>
</div>
</div>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF616036"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Newcomb, Doug [doug_newcomb@fws.gov]<br>
<b>Sent:</b> Monday, July 08, 2013 11:26 PM<br>
<b>To:</b> Baumann, Peter<br>
<b>Cc:</b> Stefan Keller; Carl Reed; osgeo-discuss; TC Discuss; standards@lists.osgeo.org<br>
<b>Subject:</b> Re: [OSGeo-Discuss] [OSGeo-Standards] Live DVD and OGC standards<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">Dr. Baumann,<br>
<br>
<div class="gmail_extra">Lighting my torch...;-)<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jul 8, 2013 at 5:12 PM, Baumann, Peter <span dir="ltr">
<<a href="mailto:p.baumann@jacobs-university.de" target="_blank">p.baumann@jacobs-university.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<br>
Finally, my personal 2 cents: I feel the future is with services, not formats will decide in future. Do I care, in my browser, whether I see PNG or JPEG or...GIF? http functionality, Ajax and the like is what I care about. Flames on... ;-)<br>
<br>
</blockquote>
<div>I like using Services when that are open standard formats, but services are ephemeral. A local source in an open standard format is better for archival / reproduction of work products.<br>
</div>
<div><br>
</div>
<div>Doug<br>
<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
cheers,<br>
Peter<br>
<br>
<br>
<br>
--<br>
Dr. Peter Baumann- Professor of Computer Science, Jacobs University Bremen<br>
<a href="http://www.faculty.jacobs-university.de/pbaumann" target="_blank">http://www.faculty.jacobs-university.de/pbaumann</a><br>
mail: p.baumann@jacobs-university.detel: +49-421-200-3178, fax: +49-421-200-493178<br>
- Executive Director, rasdaman GmbH Bremen (HRB 26793)<a href="http://www.rasdaman.com" target="_blank">http://www.rasdaman.com</a>,<br>
<div class="im"> mail: <a href="mailto:baumann@rasdaman.com" target="_blank">baumann@rasdaman.com</a><br>
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882<br>
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)<br>
<br>
<br>
<br>
<br>
________________________________________<br>
</div>
From: <a href="mailto:discuss-bounces@lists.osgeo.org" target="_blank">discuss-bounces@lists.osgeo.org</a> [<a href="mailto:discuss-bounces@lists.osgeo.org" target="_blank">discuss-bounces@lists.osgeo.org</a>] on behalf of Stefan Keller [<a href="mailto:sfkeller@gmail.com" target="_blank">sfkeller@gmail.com</a>]<br>
Sent: Monday, July 08, 2013 10:59 PM<br>
To: Carl Reed<br>
Cc: osgeo-discuss; TC Discuss; <a href="mailto:standards@lists.osgeo.org" target="_blank">
standards@lists.osgeo.org</a><br>
Subject: Re: [OSGeo-Discuss] [OSGeo-Standards] Live DVD and OGC standards<br>
<div class="HOEnZb">
<div class="h5"><br>
Hi Carl<br>
<br>
2013/7/8 Carl Reed <<a href="mailto:creed@opengeospatial.org" target="_blank">creed@opengeospatial.org</a>>:<br>
> The idea that the OGC process would significantly change something like GeoRSS is untrue.<br>
<br>
I would like to slightly disagree here and point to the ongoing<br>
GeoPackage standardization.<br>
Referring to the initial question, GeoPackage with SQLite/Spatialite<br>
"format" would have a chance to become "the Shapefile of the future".<br>
The OGC just recently had the chance to adopt this existing encoding -<br>
but unfortunately voted against in favor of an own spec.<br>
To be fair to OGC (which I respect) I'd have to say that such<br>
political decisions happen to most standardization bodies.<br>
<br>
Yours, Stefan<br>
<br>
<br>
2013/7/8 Carl Reed <<a href="mailto:creed@opengeospatial.org" target="_blank">creed@opengeospatial.org</a>>:<br>
> Allan -<br>
><br>
> I respectfully disagree with your comment regarding the authors not wanting to bring GeoRSS into the OGC. I know that Raj, myself and other original authors would support bringing GeoRSS into the OGC as is.<br>
><br>
> The idea that the OGC process would significantly change something like GeoRSS is untrue. A good recent example is Open GeoSMS. That candidate standard was developed externally and submitted into the OGC. The normative content was not changed at all other
than making one tag consistent with some IETF RFCs (HELD, LoST, etc). We also separated the normative text from the informative examples (primer) which made the standard very short and easier to understand. Additional "eyes" on a document does not necessarily
mean any normative change but does mean improvement to the document (grammar, wording, clarity, etc).<br>
><br>
> Cheers<br>
><br>
> Carl<br>
><br>
><br>
> ----- Original Message -----<br>
> From: "Arnulf Christl" <<a href="mailto:arnulf.christl@metaspatial.net" target="_blank">arnulf.christl@metaspatial.net</a>><br>
> To: <a href="mailto:standards@lists.osgeo.org" target="_blank">standards@lists.osgeo.org</a>, "TC Discuss" <<a href="mailto:tc-discuss@lists.opengeospatial.org" target="_blank">tc-discuss@lists.opengeospatial.org</a>><br>
> Sent: Monday, July 8, 2013 9:11:27 AM<br>
> Subject: Re: [OSGeo-Standards] [OSGeo-Discuss] Live DVD and OGC standards<br>
><br>
> On 08.07.2013 14:14, Rushforth, Peter wrote:<br>
>> Hi Allan,<br>
>><br>
>>> The counter-example is actually GeoTIFF, which was proposed<br>
>>> as an OGC format a long, long time ago, by the original<br>
>>> authors of the spec. At the time, it was rejected<br>
>>> specifically because the TC felt that OGC should not be<br>
>>> standardizing file specs, but rather should be standardizing<br>
>>> interfaces.<br>
>><br>
>> Ironic, because the strength of the Web is based on 'file' specs. The<br>
>> geo community needs to think less about interfaces and more about<br>
>> how to communicate state through "files".<br>
>><br>
>><br>
>> Cheers,<br>
>> Peter<br>
><br>
> Peter,<br>
> so true, I couldn't agree more. Why is it that there is a perception<br>
> that the OGC should not work on data formats but only interfaces? Is<br>
> this still the case? With GML and KML there are two strong existing data<br>
> standards. GeoPackage is not exactly "just" a media format but ships<br>
> with code - an ideal package so to say, and by any means not just an<br>
> interface standard.<br>
><br>
> GeoRSS and GeoJSON would not be hard to go forward with but for some<br>
> reason it never happened.<br>
><br>
> Cheers,<br>
> Arnulf<br>
><br>
> --<br>
> Arnulf Christl (Executive Director)<br>
> Open Source Geospatial Software, Data and Services<br>
> <a href="http://www.metaspatial.net" target="_blank">http://www.metaspatial.net</a><br>
> _______________________________________________<br>
> Standards mailing list<br>
> <a href="mailto:Standards@lists.osgeo.org" target="_blank">Standards@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/standards" target="_blank">http://lists.osgeo.org/mailman/listinfo/standards</a><br>
> _______________________________________________<br>
> Standards mailing list<br>
> <a href="mailto:Standards@lists.osgeo.org" target="_blank">Standards@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/standards" target="_blank">http://lists.osgeo.org/mailman/listinfo/standards</a><br>
_______________________________________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org" target="_blank">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
_______________________________________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org" target="_blank">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>Doug Newcomb</div>
<div>USFWS</div>
<div>Raleigh, NC</div>
<div>919-856-4520 ext. 14 <a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a></div>
<div>---------------------------------------------------------------------------------------------------------</div>
<div>The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>