Why is there no non-metric area function?
Closed this issue · 5 comments
We have metric equivalents for most functions in GeoSPARQL, but not for the function area, which in itself returns the area in squaremeters.
Was there a special reason why we did not include a metric and non-metric version of area and should we do so?
I think it was an oversight. And while we are at it, the length function seems to be also missing a metric twin. And funcs:length is missing from the funcs: collection in funcsrules.ttl.
If there is nothing else amiss, I can propose a PR to fix the omissions.
I think that would be great
Taking a better look at the situation, I see that the length and area functions already are metric. So I think I finally understand the question. Is there a need for length and area functions that have a second argument to specify a unit IRI?
I would think there is not, because for use cases where a non-metric output is necessary (probably a relatively small amount), it is very easy to multiply the output with a conversion factor.
On the other hand, one could argue it is a matter of consistency: other functions (distance and buffer) do have a metric version and a version for use with arbitrary units. But then again the non-metric versions of those functions were already in GeoSPARQL 1.0, so it would not be possible to have metric versions only.
I think it is OK to fully embrace the SI (and hence, the metric system) from now on.
Anyway, a small fix is required for funcsrules.ttl, and the area function has something strange in its definition, for which I made a new issue (381).
I think the functions area and length are enough, even if they are metric. It is just a matter of consistency, as you state, and we can discuss it later on if that is a problem.
The non-metric area function has made it in GeoSPARQL 1.1, so I will close this issue here