Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for GeoJSON GeometryCollections #32747

Open
tastrax opened this issue Nov 9, 2019 · 10 comments
Open

Add support for GeoJSON GeometryCollections #32747

tastrax opened this issue Nov 9, 2019 · 10 comments
Labels
Data Provider Related to specific vector, raster or mesh data providers Feature Request

Comments

@tastrax
Copy link

tastrax commented Nov 9, 2019

Feature description.
Allow the use of geojson collections

Additional context
Many geojsons now have mixed geometries and unfortunately QGIS does not display them in the map interface. In the example below points work but not the collections

Sample URL - http://www.rfs.nsw.gov.au/feeds/majorIncidents.json

should match - https://www.rfs.nsw.gov.au/fire-information/fires-near-me

@andrewharvey
Copy link
Contributor

andrewharvey commented Nov 29, 2019

I just ran into this now, geojson.io displays the Polygons within the GeometryCollection, but not QGIS.

PS. I try to maintain https://github.com/beyondtracks/nsw-rfs-majorincidents-geojson which aims to clean up RFS's feed based on my personal preferences. It also tries to remove unnecessary GeometryCollections, eg. a GeometryCollection containing just a single Point gets simplified to a Point, but where you have a Point for the icon/centroid and a Polygon for the fire extent, GeometryCollection is the only way to handle this.

Update: I've updated the repo above to accept an --avoids-geometrycollections argument to explode out geometry collections. The updated feed is at https://www.beyondtracks.com/contrib/nsw-rfs-majorincidents-nogeometrycollections.geojson

@andreasneumann
Copy link
Member

andreasneumann commented Nov 29, 2019

@andrewharvey and @tastrax - this is because of the fact that QGIS only supports one geometry type per layer.

What QGIS could do is offer to extract either points, linestrings or polygons from the Geojson, meaning that only parts of the geometries of a geometry collection would be displayed.

Or it could offer to paste it as several layers.

@tastrax
Copy link
Author

tastrax commented Nov 29, 2019

I would be happy pasted as several layers but I would assume that it would no longer be a “live” layer that I could refresh over time? @andreasneumann

@andrewharvey
Copy link
Contributor

andrewharvey commented Nov 29, 2019

Yep I'd expect it to split into separate layers, it already does this for mixed geometry features within a feature collection, just not mixed geometry within a GeometryCollection for a single feature.

This does mean that you'll end up with duplicate features and loose the association between the items in the GeometryCollection, but I think that's fine.

@andreasneumann
Copy link
Member

I still hope that one day QGIS will support mixed geometry types per layer natively. We can already mix types by using geometry generators ... but this is just for display.

Of course there are lots of problems ahead, because many parts in the code base assume there is only one geometry type per layer. Perhaps with QGIS 4.x we could start introducing these mixed geometry layers ...

@kachkaev
Copy link

kachkaev commented Jan 30, 2021

I wonder if this could be solved with a new layer preference, in which we could specify the mapping between the original GeoJSON geometry and the geometry we want to show. If a have a geometry collection with a point and a polygon, I would define something like this in one layer filterByType($geom, "Point"), then clone it and change the expression to filterByType($geom, "Polygon").

In addition to solving the GeometryCollection problem, this setting would enable some other interesting cases. For example, if my original features contain a pair of bbox polygon and point on surface, I’ll be able to configure QGIS to draw vectors between the centre of the bbox and the given point without having to create new files. Here is a pseudo-expression to do that: makeLine($geom[0], centerOf($geom[1])).

Screenshot 2021-01-30 at 18 18 42

To draw vectors and a bounding boxes for the above example now, I have to create multiple GeoJSON files and repeat feature attributes, which takes up disk space. If QGIS supported GeoJSON geometry transformation like described above, I could stick with just one FeatureCollectionGeometryCollection file and display it multiple times by defining different transform expressions in each.

@gioman gioman added the Data Provider Related to specific vector, raster or mesh data providers label Jan 31, 2021
@kaplanlior
Copy link

@tastrax Can you change this issue title to mention GeometryCollection?
Currently (3.16) importing a GeoJSON with FeatureCollection can be spitted by geometry type.

@gioman gioman changed the title GEOJSON - Collection Add support for GeoJSON GeometryCollections Aug 23, 2021
@tastrax
Copy link
Author

tastrax commented Sep 11, 2023 via email

@spwoodcock
Copy link

spwoodcock commented Feb 21, 2024

The same issue for flatgeobuf geometries wrapped in GeometryCollection.
I assume this would be solved by the same fix of parsing the GeometryCollection type.

  • Using GeoJSON, a single top-level GeometryCollection can be replaced with a FeatureCollection, which works fine (QGIS provides a picker to choose which geometry type you wish to add).
  • Flatgeobuf also supports mixed geometry types using the same picker.
  • However, loading of geometries each wrapped in a GeometryCollection is not possible. The attribute table can be viewed, but not the geometries on the map.

Example data:
fgb_data_geomcol.zip

You may ask, why not just remove the GeometryCollection wrapper from each geom, before converting to flatgeobuf. The issue is that importing flatgeobuf files containing mixed geometry types does not work in PostGIS. The geoms must first be homogenised by wrapping in a GeometryCollection for each geom using -nlt GEOMETRYCOLLECTION, before they are accepted by ST_FromFlatGeobuf.

@tjhokietiger
Copy link

I have run into this issue recently, as well. I have GeoJSON files (per a spec) with four different types of features. Some have simple geometries (eg., Polygon or MultiPolygon) and some have GeometryCollections containinig both Points and Multipolygons (i.e, center-points and detections). Each type also has a completely different set of properties. 3 of the feature types basically encode metadata about the overall file contents and sources (eg. images that were used), with the bulk of the features of the last type constituting what we would consider a traditional "attribute table". Currently, I am using python code to replace the items with GeometryCollections with just the polygon item and writing it to a 2nd file. It fixes my immediate display problem in QGIS, but not the manipulation problem.

I think @andreasneumann is on the right track, as QGIS 4.0 takes shape, we need a better way to handle these not-so-tabular data formats like GeoJSON, without losing connection to the original data. The Layer should represent the entire dataset, but then consist of several "sublayers" of the parts of the dataset that are similar - i.e., have similar geometry types and similar properties.

Regarding mixed geometries and collections, is there a good reason why they could not be represented/displayed as single object, where the user can decide (e.g., via symbology) which to display (either or both or many). Maybe points and polygons and lines could be addressed via different sublayers or sub-sublayers. Thoughts anyone...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Data Provider Related to specific vector, raster or mesh data providers Feature Request
Projects
None yet
Development

No branches or pull requests

8 participants