FYI, I tried to follow the link for information on BXML on the cubewerx site, but I got a page missing error at the OGC.
Landon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luis W. Sevilla Sent: Saturday, November 17, 2007 11:08 AM To: OSGeo Discussions Subject: Re: [OSGeo-Discuss] idea for an OSGeo project -- a new, open dataformat 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 Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss