[postgis-devel] ST_AsGeobuf

[Björn Harrtell]

Agreed, I wasn't being totally serious about the comparison.

My main point is that regardless of the specification stability and
intentions of Mapbox the format is useful and has been for upwards a year.
For some use cases there are no good alternatives, in my opinion. Also
consider that it's free under the ISC license.

In either case, I still would like review and test feedback as it would be
helpful as input towards vector tile output support, being perhaps a more
stable and generally useful output format.

/Björn

2016-09-12 15:20 GMT+02:00 Javier Santana <jsantana at carto.com>:

> Hey,
>
> To give some context here about TWKB vs Geobuf: before actually pushing
> TWKB to a postgis release we spent a pretty interesting amount of time on
> closing the spec (specially Nicklass and Paul) and working on the
> implementation so no backwards compatibility changes could happen.
>
> Geobuf is a "format" with no actual closed spec and controlled by just a
> single company, they will not mind about changing the spec without any
> prior notice (likely not going to happen tho)
>

> Not agains this patch or anything like that, but just to clarify that
> there are actual differences between both formats.
>

>
> On Mon, Sep 12, 2016 at 2:41 PM Björn Harrtell <bjorn.harrtell at gmail.com>
> wrote:
>
>> 2016-09-12 10:46 GMT+02:00 Paul Norman <penorman at mac.com>:
>>
>>> On 9/12/2016 12:59 AM, Björn Harrtell wrote:
>>>
>>>> Hi devs,
>>>>
>>>> I've been working on a new output format function called ST_AsGeobuf
>>>> these last months. Its purpose is to serialize full query output into the
>>>> binary format Geobuf containing both geometry and attributes. The
>>>> implementation is tracked by:
>>>>
>>>> https://trac.osgeo.org/postgis/ticket/3599
>>>> https://git.osgeo.org/gogs/postgis/postgis/pulls/4 or alternatively
>>>> https://github.com/bjornharrtell/postgis/tree/asgeobuf5
>>>>
>>>> Geobuf is a binary format specified by Mapbox that can represent
>>>> similar data and structure as GeoJSON but is more compact and is faster
>>>> encode and decode. You can read more about Geobuf at
>>>> https://github.com/mapbox/geobuf which also serves as the reference
>>>> implementation to decode at a browser client side.
>>>>
>>>> Geobuf is in turn based on Googles protobuf standard which I think is
>>>> similar to a binary XML. My implementation uses the general purpose library
>>>> protobuf-c to simplify the encoding.
>>>>
>>>> I hope to be able use this work as a base to also implement support for
>>>> vector tiles as specified by Mapbox which is also based on protobuf.
>>>>
>>>> I think the implementation is ready for review and testing. If you have
>>>> any interest in Geobuf or vector tiles output support I'd appreciate review
>>>> and/or test result feedback.
>>>>
>>>>
>>> The MapBox geobuf page states "Note that the encoding schema is not
>>> stable yet". Is it premature to put this in PostGIS?
>>>
>>
>> Subjective, I think. I think Mapbox just want to disclaim backwards
>> compatibility in the eventual next major version. Obviously I find it
>> useful right now and do think it can be for others too. If needed, PostGIS
>> could support both the current spec and future ones by parameterization, or
>> drop support if deemed obsolete.
>>
>> As far as I know, Mapbox want to evolve the spec so that it can support
>> encoding/decoding as a stream, but there is no telling when/if that work
>> will be completed.
>>
>> And as a final observation, if TWKB could be accepted I think Geobuf
>> should be. :)
>>
>> /Björn
>>
>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20160912/37399cc3/attachment.html>