Closed bjornharrtell closed 2 years ago
Looks like a good solution for solving #1, thanks!
Pushed some changes in branch bjornharrtell-feature_iterator
. Maybe it's possible to push directly into this PR?
@pka I've sent and invite to my fork, that should hopefully allow you to push the fixes directly to my branch.
When using read_geojson_fc
as default function in process
a few tests fail. Do we need a way to detect bare geometry GeoJSON objects or a fallback when FeatureIterator fails?
@pka well I suppose so, read_geojson_fc assumes feature collection. I don't quite understand the api design with default function in process etc.
The process
method is called by conversion traits like GeoJson(r#"{"type": "Point", "coordinates": [10,20]}"#).to_wkt()
. So it has to support all GeoJson object types. Or to put it in an other way: in the end we need read_geojson
and read_geojson_geom
functions supporting all GeoJson object types.
@pka I can perhaps see why that is needed technically right now doesn't quite sense to me logically that read_geojson_fc
and read_geojson_geom
need to be aware of other types than the name of the function implies.
Could you add 500c91f02bc8eca6379674ea4a45e61500db0323 again?
This also includes the FeatureIterator from https://github.com/georust/geojson/pull/181 until further notice.UPDATE: now uses it from released geojson 0.22.3I'm unsure why the WKT in from_file_fc test differs from the from_file test in that WKT is not comma separated.