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
