Proposal for geometry.precision

[docuracy]

There is almost always some approximation in the expression of Point coordinates, and it would be useful to be able to indicate the degree of approximation. For example, archaeological find sites may need to be obfuscated and indicated by a grid square; locations of other features might be recorded only as within a town, county, or country.

PROPOSAL: Introduce an optional geometry.precision property, which itself has one of the following properties as outlined in this draft JSON schema:

• tolerance
• bbox
• ccodes
• citations

[rybesh]

Elsewhere (see e.g. jazzband/geojson#135) precision is used to mean the number of decimal places in decimal coordinates, so another term might be preferable here.

I also wonder whether this is something that needs to be in LPF rather than something that applications that need it could layer on top of LPF. I imagine that specific applications may have all kinds of ways that they want to deal with precision that might be difficult to anticipate ahead of time.

[docuracy]

Agreed. We're not really looking at precision but rather at granularity. Would that do?

In my experience granularity is such a common question when dealing with geodata that I think it ought to be (an optional) part of the core LP specification. That being the case, I think we should at least try to anticipate how it might be dealt with, and revise the specification as and when other use cases become apparent.

[rybesh]

Yes, I like granularity. A lot of tools use “zoom levels” for this so we might try to find a way of expressing this that is compatible with that, i.e. maybe “zoom level” is one of the ways of expressing granularity.

[rayrrr]

Thanks for this suggestion @docuracy; also I agree that granularity is a good name for this concept. However, a larger conversation has to be had about extending the scope of this package. This package's mandate is to tightly track the GeoJSON standard, IETF RFC 7946. As such, it would be preferable to create a new Python package specifically for supporting the Linked Places format/schema instead, as it is not a part of the GeoJSON standard. Thoughts?

[rybesh]

@rayrrr This issue is not about a Python package; it's about the schema for Linked Places Format. I think I might have created confusion when I mentioned the jazzband/geojson issue above—I just did that to raise the point about naming.

[docuracy]

Notwithstanding the above discussion of granularity, WHG has now implemented an approximation property for geometries as outlined in WorldHistoricalGazetteer/website#445

The only dataset in which this is currently deployed is in some of the polygons visualised at https://whgazetteer.org/datasets/838/places.

Points with approximation would appear as circles of appropriate radius and with radial fade.

I've added it in flattened form to the LP-TSV specification, and to WHG's LPF validation schema (here), but not to the LPF standard. Would it be appropriate to do so?

[rybesh]

I like this. Just a usage question: In PeriodO we use convex hulls as simplified approximations of place geometries, so I guess we would use gvp:containedWithin as the approximation type?

[docuracy]

Thanks, @rybesh, yes, that would be correct, but on checking https://vocab.getty.edu/ontology I don't see anything like gvp:containedWithin or gvp:approximateLocation. Nor can I now find them referenced anywhere online, which is embarrassing. Sorry. Various bodies (including the UK Ordnance Survey) seem to have experimented with relevant ontologies, but links to those are dead, leaving only https://opengeospatial.github.io/ogc-geosparql/geosparql11/geo.ttl

So I guess we should probably be using something like:

• geo:sfWithin
• geo:hasSpatialAccuracy

What do you think? I've updated WHG and its LPF validation schema to use those, but it's not too late to switch to something better, if it exists.

[rybesh]

Yes, I agree it’s best to stick with the geo: terms, and those seem to be the right ones. Glad to see LPF progressing!