Difference between revisions of "Software Standards"
| Line 49: | Line 49: | ||
===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=== | ===Tile Caching=== | ||
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:
- The Sunburned Surveyor
- Jeroen Ticheler
- Lorenzo Becchi
- Michael P. Gerlek (mpg)
- Tom Kralidis
- Peter Rushforth
- 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:
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?