[Geojson] FeatureCollection in FeatureCollection?

[Henrik Hjelte]

On Wed, Oct 29, 2008 at 8:32 PM, Matthew Russell
<matt.horizon5 at gmail.com> wrote:
>
> You could just define a JSON structure that contains the two geojson structures.
> e.g:
> {
>    "gas_stations": <FeatureCollection>,
>    "two_cities":  <Feature>,
> }
>
> Cheers,
> Matt
I could but I don't like it, as I tried to explain with the boundbox
argument. I want to save geoJSON as input, not plain vanilla JSON, and
be able to analyze the data to find a bounding box. Other data might
not be gas stations/route, but some other geoJSON structures. You
solution would need recoding the backend logic for each new item I
want to add.

> Christopher Schmidt wrote:
>> Why is it important that the gas stations are a FeatureCollection? I'd
>> simply make a FeatureCollection with one line, and multiple gas
>> stations.
>>
>> Regards,
>
> Yes. It's not explicitly said in the spec, but GeoJSON collections can
> (as suggested) be heterogeneous, having different flavors of features.
>
> Sean
I might want to group the gas stations as one unit of gas-stations,
because I don't want to duplicate data. Lets say I store a
brand-logotype encoded as a base64 string, and I don't want to
duplicate that across all stations.

Or I might want add a Feature refering to every house along the route.
So I have a route, 20 gas stations and 2000 houses. If I want to find
the gas stations in the geoJSON structure I will have to iterate
through 2021 objects, compared to three objects if I could group them
together into distinct FeatureCollections.

This is not very far-fetched is it?

If it is not possible I would call it a flaw in the specification.

I think either a Feature should be able to contain a Feature or
FeatureCollection in addition to geometries,  or that
FeatureCollection be able to contain Features mixed with
FeatureCollections, and a FeatureCollection also have "properties" and
optional "id" like a Feature.

/Henrik Hjelte