[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