Difference between revisions of "Software Standards"

From OSGeo
Jump to navigation Jump to search
 
(14 intermediate revisions by 5 users not shown)
Line 4: Line 4:
 
Please feel free to add content to the following sections. What I’m providing below is just a skeleton.
 
Please feel free to add content to the following sections. What I’m providing below is just a skeleton.
  
−
==OSGeo Software Standards Mailing List==
+
== OSGeo Software Standards Mailing List ==
−
 
 
−
Some of the members expressed interest in an OSGeo mailing list dedicated to software standards, but nothing materialized. Add your name to the list below if you would be interested in subscribing to such a list.
 
  
 +
Some OSGeo members expressed interest in an OSGeo mailing list dedicated to software standards:
 
* The Sunburned Surveyor
 
* The Sunburned Surveyor
 +
* [[User:ticheler|Jeroen Ticheler]]
 
* [[User:ominiverdi|Lorenzo Becchi]]
 
* [[User:ominiverdi|Lorenzo Becchi]]
 +
* [[User:mpg|Michael P. Gerlek (mpg)]]
 +
* [[User:Tomkralidis|Tom Kralidis]]
 +
* [[User:peterrushforth|Peter Rushforth]]
 
* Your Name Here...
 
* Your Name Here...
 +
 +
This list is open to discuss all kinds of  [[Standards]] regardless whether they are from the W3C, ISO or more specifically focused on spatial issues like from the [[OGC]]. Subscribe to the list here:
 +
* http://lists.osgeo.org/mailman/listinfo/standards
  
 
==Why Do Software Standards Succeed?==
 
==Why Do Software Standards Succeed?==
 +
Vendor independent, open and interoperable software standards only succeed if they solve a real world problem and are supported by many software packages.
  
 
==Why Do Software Standards Fail?==
 
==Why Do Software Standards Fail?==
  
 
==Do We Really Need Software Standards?==
 
==Do We Really Need Software Standards?==
 +
Evolution says no. Organizations say yes.
 +
* Standards can speed up interoperability and foster dissemination of compatible software, data and information.
 +
* Standards can also obstruct creativity and hinder innovation.
  
 
==What Role Do Software Standards Have In The Development Of Open Source Geospatial Software?==
 
==What Role Do Software Standards Have In The Development Of Open Source Geospatial Software?==
Line 24: Line 34:
  
 
==Should The Development Of A Software Standard Be Open? How Open?==
 
==Should The Development Of A Software Standard Be Open? How Open?==
 +
Yes, the process should be as transparent and open as a well organized Open Source project is. This does not mean that anybody can do anything but that everybody can see everything and comment on it. A strong standard requires formal processes to be able to integrate with or become part of other standards.
  
 
==Do Software Standards Have To Be Approved By A Standards Body To Be Valid?==
 
==Do Software Standards Have To Be Approved By A Standards Body To Be Valid?==
Line 32: Line 43:
  
 
==Suggested Standards==
 
==Suggested Standards==
 +
 +
''(This section is intended (I think?) to be a list of "standards" in the geo world that are examples of specifications that are/were not "formal" in the sense of coming under the OGC or ISO umbrella. -mpg)
 +
''
  
 
===Binary Open Feature Format (BOFF)===
 
===Binary Open Feature Format (BOFF)===
 
As part of my work on OpenJUMP I was interested in creating a file format that could serve as an alternative to [http://en.wikipedia.org/wiki/Shapefile ESRI Shapefiles]. ESRI publishes the Shapefile [http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf specification], but Shapefiles have some limitations that I would like to overcome. For example, the mix big-endian and little-endian data, they use DBF files to store attribute information, they have very little built-in support for metadata, and they can’t be extended to support information like topology. Still, certain aspects of Shapefiles appealed to me. The file format is binary, which means its compact and quicker to import/export. It is also conveys relatively simple information, which has allowed it to become the de facto means of transporting geospatial information. You can learn more about my intital sketches of BOFF [http://thejumppilotproject.pbwiki.com/Binary%20Open%20Feature%20Format here].
 
As part of my work on OpenJUMP I was interested in creating a file format that could serve as an alternative to [http://en.wikipedia.org/wiki/Shapefile ESRI Shapefiles]. ESRI publishes the Shapefile [http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf specification], but Shapefiles have some limitations that I would like to overcome. For example, the mix big-endian and little-endian data, they use DBF files to store attribute information, they have very little built-in support for metadata, and they can’t be extended to support information like topology. Still, certain aspects of Shapefiles appealed to me. The file format is binary, which means its compact and quicker to import/export. It is also conveys relatively simple information, which has allowed it to become the de facto means of transporting geospatial information. You can learn more about my intital sketches of BOFF [http://thejumppilotproject.pbwiki.com/Binary%20Open%20Feature%20Format here].
 +
 +
===Fast Infoset encoding of GML ===
 +
 +
This is not strictly a software standard, but rather a proposed optimization of an existing data standard.
 +
 +
GML allows XML-based encoding of geographic features.  There are simple profiles of GML which constrain what can be used in the application schema.  Since XML is a broadly and deeply adopted de facto standard for data and documents, what about basing such a (BOFF) format on GML?  People will say the performance is not good enough, so what about using a binary encoding of the XML Infoset, such as the  [http://en.wikipedia.org/wiki/Fast_Infoset "Fast Infoset"] which might help alleviate those concerns?
 +
 +
===Tile Caching===
 +
The goal of a WMS Tile Caching proposal, perhaps WMS-C for short, is to find a way to optimize the delivery of map imagery across the Internet. The proposal needs to offer ideally some means by which map clients can fetch tiles from existing servers, in such a way that the images can be cached on the server, or at an intermediate location, or even be completely pre-generated, if desired.
 +
 +
Further description [[WMS_Tile_Caching|here]].
 +
 +
''(This needs to be clarified -- there are two things going on here, I think: WMS-C and WMS-T.  One is about using WMS to request tiles, the other is about a server-in-the-middle that caches tiles. -mpg)''
 +
 +
===GeoRSS===
 +
" As RSS becomes more and more prevalent as a way to publish and share information, it becomes increasingly important that location is described in an interoperable manner so that applications can request, aggregate, share and map geographically tagged feeds."
 +
 +
web site [http://georss.org here].
 +
 +
===GeoTIFF===
 +
 +
see [http://www.remotesensing.org/geotiff/geotiff.html]
 +
 +
===Others===
 +
 +
Should we have a section for:
 +
* Shapefile?
 +
* WKB/WKT? (are these two formally or informally documented anywhere?)
 +
* GeoJSON?
  
 
==Links==
 
==Links==
Line 45: Line 88:
 
*[http://www.iso.org/iso/en/ISOOnline.frontpage National CAD Standards]
 
*[http://www.iso.org/iso/en/ISOOnline.frontpage National CAD Standards]
 
*[http://www.clock.org/~fair/opinion/open-standards.html A Take On Software Standards]
 
*[http://www.clock.org/~fair/opinion/open-standards.html A Take On Software Standards]
 +
*[http://cordis.europa.eu/aoi/article.cfm?article=1869&lang=EN "Innovation needs a new way of making standards"]
 +
 +
[[Category:Standards]]

Latest revision as of 08:24, 22 April 2008

About

There was recently some discussion on the main OSGeo mailing list about software standards. There was some general discussion about software standards, and also some specific discussion about the role of the OSGeo in the OGC, the primary geospatial standards body. I thought I would create a page on the wiki to hold some OSGeo members thoughts on software standards.

Please feel free to add content to the following sections. What I’m providing below is just a skeleton.

OSGeo Software Standards Mailing List

Some OSGeo members expressed interest in an OSGeo mailing list dedicated to software standards:

This list is open to discuss all kinds of Standards regardless whether they are from the W3C, ISO or more specifically focused on spatial issues like from the OGC. Subscribe to the list here:

Why Do Software Standards Succeed?

Vendor independent, open and interoperable software standards only succeed if they solve a real world problem and are supported by many software packages.

Why Do Software Standards Fail?

Do We Really Need Software Standards?

Evolution says no. Organizations say yes.

  • Standards can speed up interoperability and foster dissemination of compatible software, data and information.
  • Standards can also obstruct creativity and hinder innovation.

What Role Do Software Standards Have In The Development Of Open Source Geospatial Software?

Should You Have To Pay For A Copy Of A Software Standard?

What about releasing a standard under one of the Creative Commons licenses?

Should The Development Of A Software Standard Be Open? How Open?

Yes, the process should be as transparent and open as a well organized Open Source project is. This does not mean that anybody can do anything but that everybody can see everything and comment on it. A strong standard requires formal processes to be able to integrate with or become part of other standards.

Do Software Standards Have To Be Approved By A Standards Body To Be Valid?

When Does A Widely Used File Format Become A De Facto Software Standard?

What The Advantages Of Text Over Binary For Open File Formats? Is XML The Best Solution?

Suggested Standards

(This section is intended (I think?) to be a list of "standards" in the geo world that are examples of specifications that are/were not "formal" in the sense of coming under the OGC or ISO umbrella. -mpg)

Binary Open Feature Format (BOFF)

As part of my work on OpenJUMP I was interested in creating a file format that could serve as an alternative to ESRI Shapefiles. ESRI publishes the Shapefile specification, but Shapefiles have some limitations that I would like to overcome. For example, the mix big-endian and little-endian data, they use DBF files to store attribute information, they have very little built-in support for metadata, and they can’t be extended to support information like topology. Still, certain aspects of Shapefiles appealed to me. The file format is binary, which means its compact and quicker to import/export. It is also conveys relatively simple information, which has allowed it to become the de facto means of transporting geospatial information. You can learn more about my intital sketches of BOFF here.

Fast Infoset encoding of GML

This is not strictly a software standard, but rather a proposed optimization of an existing data standard.

GML allows XML-based encoding of geographic features. There are simple profiles of GML which constrain what can be used in the application schema. Since XML is a broadly and deeply adopted de facto standard for data and documents, what about basing such a (BOFF) format on GML? People will say the performance is not good enough, so what about using a binary encoding of the XML Infoset, such as the "Fast Infoset" which might help alleviate those concerns?

Tile Caching

The goal of a WMS Tile Caching proposal, perhaps WMS-C for short, is to find a way to optimize the delivery of map imagery across the Internet. The proposal needs to offer ideally some means by which map clients can fetch tiles from existing servers, in such a way that the images can be cached on the server, or at an intermediate location, or even be completely pre-generated, if desired.

Further description here.

(This needs to be clarified -- there are two things going on here, I think: WMS-C and WMS-T. One is about using WMS to request tiles, the other is about a server-in-the-middle that caches tiles. -mpg)

GeoRSS

" As RSS becomes more and more prevalent as a way to publish and share information, it becomes increasingly important that location is described in an interoperable manner so that applications can request, aggregate, share and map geographically tagged feeds."

web site here.

GeoTIFF

see [1]

Others

Should we have a section for:

  • Shapefile?
  • WKB/WKT? (are these two formally or informally documented anywhere?)
  • GeoJSON?

Links

Retrieved from "http://wiki.osgeo.org/w/index.php?title=Software_Standards&oldid=24473"