Is geospatial Parquet story going to be messy? So up to now GeoParquet was regular Parquet + a bunch of metadata telling "oh this binary column holds WKB geometries in case you care" (like GeoPackage). And now there's this proposal https://github.com/apache/parquet-format/pull/240 about adding a native Parquet geometry type.
@EvenRouault At that point, for example a potential future GeoParquet 1.x spec release could say that a geometry column encoded as WKB can use the GEOMETRY logical type in addition to a plain BYTE_ARRAY physical type.
(that said, I also not entirely sure of the added value compared to what GeoParquet already offers)
@jorisvandenbossche@EvenRouault It would probably be opt-in for quite some time if it does ever happen while readers catch up. I wish they would just enable an extension type + metadata + blob for custom column stats (which would enable approximately the same thing)
I'm always amazed how some bugs can remain unknown for such a long time. It just took me 12 years to figure out that I got the order of matrix multiplication in OGR PDF vector reading wrong... (for my own defense the PDF spec is 1310 page long). Now fixed per https://github.com/OSGeo/gdal/pull/9874
Remainder for those not aware: you don't even need a local installation of GDAL to convert between geospatial formats (not all GDAL supported formats, but a large subset). Just try https://gdal3.js.org/
Are there Korean users here interested in better support for vertical transformations in PROJ for Korea? EPSG references a KNGeoid18.gri grid file, to transform between KGD2002 and KVD1964 height , likely distributed by National Geographic Information Institute (NGII). If it can be provided under one of the open licenses listed at https://github.com/OSGeo/PROJ-data, it could be integrated into the PROJ-data repository, and be usable by PROJ, @gdal, @qgis etc. Korea lacks an entry in https://cdn.proj.org
@EvenRouault@tudelft3d@sozip@qgis One more picture in full screen 3D using the lod22_3d layer and online elevation data to place OSM layer at correct elevation.
When mentionning that GDAL at the NumFocus summit has support for ~ 250 file formats, non-geo people were like "what's wrong with you geo folks ?". What's wrong with us indeed ? The equivalent of GDAL in neuroimaging has "only" support for ~ 10 formats (https://nipy.org/nibabel/). Guessing: perhaps because creating a medical imaging processing software requires some kind of certification & high costs whereas you just need a handful of devs to create a average GIS with its inhouse format?