On Wed, Nov 24, 2021 at 3:10 PM Regina Obe wrote:
> 3) Given it is demonstrated it can work fine with leaflet and openlayers
> means it is possible to hook it into something like
>
> https://github.com/CrunchyData/pg_featureserv
>
> as an alternative format to geojson (not saying you should Mart
Sufficiently chastised. Based on Regina's comments, I might have a use
case for it.
On Wed, Nov 24, 2021 at 3:10 PM Regina Obe wrote:
> As mentioned on IRC just reiterated here.
>
>
>
> I would like to see ST_AsFlatGeoBuf in there. Here are my reasons.
>
>
>
> 1) To Bruce’s point that sure ogr_
As mentioned on IRC just reiterated here.
I would like to see ST_AsFlatGeoBuf in there. Here are my reasons.
1) To Bruce’s point that sure ogr_fdw can read it, I’m more interested in the
writing of it (which at least I can’t do from scratch with ogr_fdw) and getting
out of the database
Even though I spent quite a bit of effort on implementing this stuff and
I'm sure I can fix the crashers I agree with the arguments to remove it.
That is, 1GB limit is really bad and better to use GDAL which has a well
maintained impl of it.
If there was a way to stream in and out binary with cust
FWIW I say remove it and seriously think about not including it at all.
Looks like you can use the format right now via ogr_fdw using GDAL.
On Wed, Nov 24, 2021 at 12:51 PM Regina Obe wrote:
> FWIW it’s already in GDAL since 3.1 and yah GDAL is a better home since it
> doesn’t have the 1GB Post
FWIW it’s already in GDAL since 3.1 and yah GDAL is a better home since it
doesn’t have the 1GB PostgreSQL limitation
https://gdal.org/drivers/vector/flatgeobuf.html
Also here are OpenLayers and Leaflet examples for those not familiar with the
format
OpenLayers: https://flatgeobuf.or
The table is not created during update, but should be updated with new records
and corrections as needed. I’ve confirmed I see the same issue in one of my
databases that was upgraded to 3.1.4 (5757 rows) (compared to a fresh install
8500 rows).
I’ve ticketed here:
https://trac.osgeo.or
Hi,
I have not seen flatgeobuf in the wild, and I believe it can be safely
removed.
The current implementation is impaired by Postgres' life choices of 1GB
limit and thus not usable for any data, just size-limited subset. ogr2ogr
seems like a better suited place for it to reside.
I'm -0 on addin
You can safely ignore this since your query returns 2.4.9
SELECT postgis_scripts_installed(), postgis_scripts_released();
postgis_scripts_installed | postgis_scripts_released
---+--
2.4.9 | 2.4.9 r0
The issue is we start
This is a PSC vote, but we would like some feedback on this from packagers
and users as such comments will sway our vote.
We have two blockers that center around the new FlatGeoBuf format.
https://trac.osgeo.org/postgis/ticket/5005 (this one is easily
replicatable)
https://trac.osgeo.org/postgi
10 matches
Mail list logo
