"A feature collection contains features of only one feature type" - really? In INSPIRE terms?

[PeterParslow]

This appears as the last bulleted principle, and then again as requirement /req/pre-defined/spatial-object-type

The problem is that if applied to the current INSPIRE models, this would mean (for example) that most "lines" in an Address would appear in different feature collections, and in a network, the links & nodes would be in different collections, and the Transport Properties (for example) would be in yet another.

I actually suspect that when this was written, a simplified schema was in mind. If that's the case, could it be made explicit that this isn't actually referring to the INSPIRE spatial object types defined in the regulation(s)

If on the other hand, this is what is meant, could you explain how this helps the data user? How they should discover which related Feature Collections they will need to navigate to obtain a useful set of data?

[cportele]

I agree that this constraint is in some cases unpractical, as you point out.

If I remember correctly, it was added because of the provisions for the mandatory operation Describe Spatial Object Type in the download service regulation.

On the specific topic of encoding address data for INSPIRE: I would only offer address features via the API and embed (the information from) the address components in the address feature. So, a single collection with a tag link to Address.

[heidivanparys]

If I remember correctly, it was added because of the provisions for the mandatory operation Describe Spatial Object Type in the download service regulation.

Yes indeed.

Note: from http://docs.opengeospatial.org/DRAFTS/17-069r4.html

This standard does not include any requirements about how the features in the dataset have to be aggregated into collections. A typical approach is to aggregate by feature type but any other approach that fits the dataset or the applications using this distribution may also be used.

As for

The problem is that if applied to the current INSPIRE models, this would mean (for example) that most "lines" in an Address would appear in different feature collections, and in a network, the links & nodes would be in different collections, and the Transport Properties (for example) would be in yet another.

I actually suspect that when this was written, a simplified schema was in mind. If that's the case, could it be made explicit that this isn't actually referring to the INSPIRE spatial object types defined in the regulation(s)

If on the other hand, this is what is meant, could you explain how this helps the data user? How they should discover which related Feature Collections they will need to navigate to obtain a useful set of data?

isn't this actually very similar to what is done in WFS? E.g. with an example from a Belgian WFS with addresses, found via the INSPIRE Geoportal

<wfs:member>
	<ad:Address gml:id="adres_1000000">
		<gml:identifier codeSpace="http://inspire.ec.europa.eu/ids">https://data.vlaanderen.be/id/adres/1000000</gml:identifier>
		<ad:inspireId>
			<base:Identifier>
				<base:localId>1000000</base:localId>
				<base:namespace>https://data.vlaanderen.be/id/adres</base:namespace>
			</base:Identifier>
		</ad:inspireId>
		<!-- ... -->
		<ad:component xlink:href="http://vocab.belgif.be/auth/refnis1995/1000#id"/>
		<ad:component xlink:href="https://data.vlaanderen.be/id/gemeentenaam/11035"/>
		<ad:component xlink:href="https://data.vlaanderen.be/id/postinfo/2520"/>
		<ad:component xlink:href="https://data.vlaanderen.be/id/straatnaam/6301"/>
	</ad:Address>
</wfs:member>

So the WFS advertises several feature types (or you could say, feature collections, with each collection containing features of one feature type). The Address contains a link to the other features. That may be a link to the same WFS, or it may be a link to another WFS (or perhaps a completely different web service...). Well, that is the theory, but I don't know how much that is used. It is easier providing a GML file containing all the features, via an Atom feed, then the xlink:href="#id1234 syntax can be used, and you know that the other feature is in the same file and you kind of know what you get...

Those principles would be the same for OGC API Features providing features in GeoJSON then, if you don't use a simplified schema, you provide a link (I actually don't know the exact syntax for that in GeoJSON) to a feature in another collection provided by the same service, or to a feature provided by another service. And if services use the modern web development practices, following those links should actually be possible.

It would perhaps be useful documenting in the metadata if the features provided by the service refer to features in other services? In what other ways can users be guided?