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.