Should FlatGeobuf support features with null geometries when spatially indexed? #260
Replies: 3 comments 9 replies
-
|
definitely, it's nice to keep all related data in one place, |
Beta Was this translation helpful? Give feedback.
-
|
Revisited thought about this.. and perhaps all that is needed is an aux feature count for the features with null geometries. |
Beta Was this translation helpful? Give feedback.
-
|
Just a little motivator for this one as it's the only drawback I know of flatgeobufs in read-only scenarios. If this was fixed we'd finally know what to tell to GIS users asking what format they should use :-D |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
FlatGeobuf supports null geometries in the spec in some capacity but it has not been well explored.
Recently it was discovered that it doesn't currently seem possible to support the specific case when you want spatial indexed FlatGeobuf and the same time want it to contain features without geometry. See OSGeo/gdal#7401 for more details.
In short, it is believed that since the header has a feature count that is also used to establish the index size and structure it must represent indexable features. Since features without geometry cannot be indexed there is a problem.
The FlatGeobuf spec can be extended with backwards compatibility if done carefully and I believe there could be a way to add the needed metainformation to support this case but I'm hesistant to do it / invest time into it since I don't personally like the mixed concern of non spatial and spatial features in the same file or feel I have use for it myself.
Beta Was this translation helpful? Give feedback.
All reactions