Units

[1ec5]

What units are osm2rdf:length and osm2rdf:area expressed in? Are they in physical or projected units?

At one point I thought areas might be in hectares, but I see for example that this area covering 106 500 square meters (11 ha) has an osm2rdf:area of 1.08298e-05, while this way 122.4 meters long has an osm2rdf:length of 0.001181.

[LorenzBuehmann]

I'd just guess the unit is degrees as the OSM data is WGS84 - so for area this would be the very rare unit square degrees though expected without reprojecting to a metric CRS.
For clarification we should ask @patrickbr

[patrickbr]

Indeed, the unit for osm2rdf:area is "square degrees" at the moment, and for osm2rdf:length, it's degrees (both WGS84). This is obviously not optimal, and it should be trivial to change this to meters / square meters.

I have opened an issue for this.

[tuukka]

It's not trivial in the sense that a degree doesn't have the same width in meters unless the latitude stays constant. Often, the area is approximated using a simple algorithm whose source I'm not able to download although e.g. turf-area contains an implementation of it: https://ntrs.nasa.gov/citations/20210005701

[tuukka]

While I was writing the previous comment, the redirection service woke up and took me here for a succesful download: https://dataverse.jpl.nasa.gov/file.xhtml?fileId=45024&version=2.0

[patrickbr]

Thank you for the links! At least for osm2rdf:length, it should be sufficient to simply use the Haversine formula. If my intuition is not entirely off, simply using the Haversine formula for the distance calculation in classic methods for computing the area of a polygon should already yield a pretty good approximation. But we should test this on large polygons (country borders) first, of course.

[1ec5]

Yes, Turf uses Haversine, though there’s been some back and forth in the past about which Earth radius constant to use. Mapbox also developed cheap-ruler as a performance optimization, but I don’t know if it would matter in this case.