Luis, good to hear support for a GML version of Peter Vretanos' BXML. When we were working on the WFS Simple API last year Peter and I did some more work on it here:
http://www.ogcnetwork.net/node/189
(schema and examples)

I think it's slightly different (simpler and geometry harmonized with GeoRSS GML) than what's at http://www.cubewerx.com/web/guest/bxml, but the idea is the same.
---
Raj


On Nov 17, 2007, at 2:08 PM, Luis W. Sevilla wrote:

Hi,
 +1 for GML with BXML encoding as next open standard. GML 3.* with his
ability to be 'profiled' seems to be on the base of  almost all and
every OGC norm being proposed on last 2-3 years. As Rob Atkinson said to
me, BXML may be an encoding for GML, in a way no standard needs to be
modifyed to support this encoding, only implementors must add support to it.
   At gvSIG we're currently working both on a low level library for
reading and writing GML 3.* + other GML alike formats, disacopled of
our object model, and a java port of this cubewerx BXML encoder/ decoder.
We hope to release early results by the end of 1st term next year.
Maybe the way of push the standard (both OGC and ISO) it's by simply
implement parsers and writers, and use it a widely as possible.

   greetings
      Luis
Paul Spencer wrote:

Cubewerx created a binary XML implementation that is open source.
They claim substantial benefits, so perhaps GML plus a binary XML
library could be an alternative?

http://www.cubewerx.com/web/guest/bxml

Cheers

Paul

On 15-Nov-07, at 5:21 PM, Lucena, Ivan wrote:

Sampson,

I am not a GML guru and I don't know if a binary version exists
already, but I would imagine that HDF5 would be a excellent choice
by its own hierarchical nature. I mean, we can use GML as a schema
to store the data in binary format in the HDF5 format.

Best regards,

Ivan

Sampson, David wrote:

Alright,
Here are some other thoughts.
First off what about a open office (open base) type approach... This
mimmics the ESRI MSAccess approach and seams to work well for non
server
environments. Also open office is a good environment for some basic
applications.
Next, what ever happened to the adoption of GML... Was GML not
supposed
to be the NEXT interchange fomrat?  Perhaps this is a good
discussion to
include the GML gurus in. The whole discussion of going with a binary
GML format makes sense and GML is already used for many web mapping
(feature) services. It sounds like a duplication of GML to me...
Unless
someone can offer a direct compare and contrast between the concept
here
and the GML/Binary GML concept.
In either case being able to convert to and from GML would be a
necesity
for wide adoption IMHO.
Another thought is to encourage some of the proprietary formats to
open
up. What would it take to get ESRI on board to open up the format
(open
as in free speech). What about other non-open standards? Once it's
open
then we can bring the SHP format to modern day useage. Surely much of
the format could be salvaged.
Besides, if you want wide adoption of an open format then why not
go for
those players who hold greatest market share.
Some thoughts.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of P Kishor
Sent: Tuesday, November 13, 2007 09:53
To: OSGeo Discussions
Subject: [OSGeo-Discuss] idea for an OSGeo project -- a new, open data
format
So, I am thinking, Shapefile is the de facto data standard for GIS
data.
That it is open (albeit not Free) along with the deep and wide
presence
of ESRI's products from the beginning of the epoch, it has been widely
adopted. Existence of shapelib, various language bindings, and
ready use
by products such as MapServer has continued to cement Shapefile as the format to use. All this is in spite of Shapefile's inherent drawbacks,
particularly in the area of attribute data management.
What if we came up with a new and improved data format -- call it
"Open
Shapefile" (extension .osh) -- that would be completely Free,
single-file based (instead of the multiple .shp, .dbf, .shx, etc.),
and
based on SQLite, giving the .osh format complete relational data
handling capabilities. We would require a new version of Shapelib,
improved language bindings, make it the default and preferred
format for
MapServer, and provide seamless and painless import of regular .shp
data
into .osh for native rendering. Its adoption would be quick in the
open
source community. The non-opensource community would either not give a
rat's behind for it, but it wouldn't affect them...
they would still work with their preferred .shp until they learned
better. By having a completely open and Free single-file based,
built on
SQLite, fully relational dbms capable spatial data format, it would be
positioned for continued improvement and development.
Is this too crazy?
--
Puneet Kishor
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


+-----------------------------------------------------------------+
|Paul Spencer                          [EMAIL PROTECTED]    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+





_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss


_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Reply via email to