(breaking suggestion) Improve `zone_id` interoperability with GeoJSON implementations

[sargunv]

In zones.json, zone_id is currently defined a member of the GeoJSON Feature.

GeoJSON does allow for foreign members, but notes that it may cause reduced interoperability:

Members not described in this specification ("foreign members") MAY be used in a GeoJSON document. Note that support for foreign members can vary across implementations, and no normative processing model for foreign members is defined. Accordingly, implementations that rely too heavily on the use of foreign members might experience reduced interoperability with other implementations.

My experience is that GeoJSON implementations in strongly typed languages often ignore such foreign members, so placing the zone id as a foreign member will make it harder to work with.

The GeoJSON spec says commonly used feature identifiers SHOULD be in a member called id:

If a Feature has a commonly used identifier, that identifier SHOULD be included as a member of the Feature object with the name "id", and the value of this member is either a JSON string or number.

It's a breaking change to the GOFS spec, but I'd recommend aligning with the GeoJSON spec by either renaming zone_id to id or, if the zone_id name is desired, moving it to the Feature's properties object (right next to name).

For clarity:

• Current spec: Feature.zone_id (foreign member)
• Proposal 1: Feature.id
• Proposal 2: Feature.properties.zone_id

My preference is for the latter option; placing it in Feature.properties.zone_id.