tantekone big challenge for h-entry is - how do we allow/encourage innovation with / on top of it, without it just becoming a dumping ground for dozens of new properties?
aaronpkto avoid needing to add new properties for different kinds of objects, you'd have to have a way for h-entry to have a place to put unknown/new objects
aaronpkfor example, I want to publish my bike rides, which have a set of properties like "duration" and "average speed" not to mention the actual route data with all the location points.
aaronpkconsumers of an h-feed that know how to render routes would just need to look for whether there is an h-x-route object as one of the children of the h-entry
aaronpkright now i'm storing the route object on a property called "route" internally. when I want to use it, I check "is there a value for the route property" and then use it
aaronpkthis may be a problem if I want to store more than one object of the same type that mean different things, like a start and end location (contrived example)
aaronpkit's not really directions summary since it's actual location traveled rather than planned, and i would also never describe the route in words used to describe directions
aaronpkeven if there were a good API for that, there's still the problem of describing the route as I run through the park where there are no street names and the path wanders around
tommorristantek: OSM has Nominatim for reverse geocoding and there are open source routing engines on top of OSM data (have seen them support cars, cycles, walking, even horse riding)
aaronpki just think a route doesn't make sense to have timing information necessarily, nor does it convey that it is a thing that happened at a single point in the past