requirements.txt

This is a placeholder for requirements and design directions for the spatial extension. This writing is from scratch, and not so much aiming to comment on existing schema.org spatial constructions.

The schema.org spatial extension must be self explanatory and not overly complex. We assume that the storage and indexing mechanisms for schema.org data do not have capabilities that facilitate spatial analyses (such as geo functions).

There will be one hasLocation property that points to a Location class.   
More specific types of a location property, such as jobLocation, will be superseded by the general property hasLocation.
It is not necessary to say (as it is now in schema.org):
JobPosting jobLocation Place
One could just as much say:
JobPosting hasLocation Location 

In principle, every schema:Thing is capable of having a hasLocation property that points to a Location class. For some classes this might be illogical to have a location, but we leave it up to the modeller to decide (AAA principle).
A Location has attributes, such as a shape, a coordinate reference system (or maybe just assume WGS84?) and coordinates.
The shape of a location can be point, line or polygon (maybe in the future, if necessary, derivatives thereof).

The attributes of Location are mostly rdf:Properties that point to literals, or coded lists of type string.

There are additional properties that contain the topology of a location. This topology is annotated, not calculated in the data. These topology attributes are different from the common geospatial topology properties (such as overlap, disjoint, meet) to make them more understandable for the general public. Examples are: nextTo, above, inside.

The hasLocation property has an inverse property (isLocationOf)

Although not particularly belonging to the "spatial scope" we also need general attributes that describe the "dublin core" kind of properties, such as "source", "created" etc. 
This must be at the schema:Thing level.