[gdal-dev] Esri REST PBF support
Even Rouault
even.rouault at spatialys.com
Wed Jul 23 04:04:04 PDT 2025
Craig,
What would you be your idea: decode the PBF into JSON ? otherwise
re-using the existing code of the ESRI JSON driver is going to be
difficult as it assumes JSON everywhere.
For PBF reading, we have ogr/ogrsf_frmts/gpb.h used both by the OSM PBF
driver and the MVT driver. This is probably a bit tedious to use than
code generated by the protobuf compiler, but at least this saves an
extra dependency.
I'm a bit skeptical about the ability of a LLM to generate code that
will insert nicely into GDAL, but let's see...
Even
Le 23/07/2025 à 00:04, Craig de Stigter via gdal-dev a écrit :
> Hi folks
>
> OGR has support for ESRI FeatureService endpoints via the ESRI JSON
> <https://gdal.org/en/stable/drivers/vector/esrijson.html> driver.
> I am wondering if there would be interest in adding PBF support to
> that driver, so that we could ingest the more efficient PBF versions
> of those endpoints.
>
> As far as I can tell, this is *different* and unrelated to the OSM PBF
> format that GDAL already supports.
>
> Feature servers we have come across that support PBF seem to return
> query results much faster and more reliably in PBF rather than JSON.
>
> We have some Python code internally (not using GDAL) that handles
> the PBF, but it performs poorly due to being computation code in
> Python. I am investigating ways to speed it up using other languages.
> As part of this I may be in a position to convert it to C++ and
> contribute it to GDAL, if there is interest. I am no C++ developer but
> am becoming proficient with Claude Code :)
>
> I would lean towards implementing the PBF support as a by-default
> optimisation on the existing ESRIJSON driver, if the server advertises
> support for PBF - with a config option to force use of JSON if
> necessary. A separate driver would be an alternative but seems
> unnecessary since the PBF structure is quite similar to the JSON
> structure (the main difference is that geometries are encoded more
> efficiently)
>
> I haven't given much time towards investigating how to do this in
> GDAL, but would appreciate any tips or discussion.
>
> --
> Regards,
> Craig
>
> Platform Engineer
> Koordinates
> koordinates.com <http://koordinates.com/> / @koordinates
> <https://twitter.com/koordinates>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250723/57f87c47/attachment.htm>
More information about the gdal-dev
mailing list