[Routing] Crowdsourced costing - offer of writing a client+metric for it
Marcus Wolschon
Marcus at Wolschon.biz
Wed Dec 3 08:44:24 GMT 2008
On Wed, 3 Dec 2008 00:27:46 -0800 (PST), j2megps <j2megps at yahoo.com> wrote:
> Hi Marcus,
>
> I refer to your previous post:
> <<<
> I suggest a service that collects the following data:
>
> collection:
> * vehicly-category (car,bike,foot,ship,other)
> * vehicle-type (String, freely chosen with some presets)
> ** vehicly-subtype (flow, normal, fast)
> ** used metric (String, freely chosen, presets: fastest, shortest,
> efficient, scenic, mapping)
> * average speed in km/h
> * way-ID, startNode, endNode
> * day = (weekday,weekend,holiday)
> * time = (night,morning,afternoon)
> ** sub-time = (early,mid,late)
>
> example: car-fast, 123-456 on way 789 with 78km/h at early morning
>>>>
>
> When I read your post, I just wonder how you store those information
above
> into current data model (node/way/relation)?
Hello,
I did not propose to store it in the current datamodel that is
used for the map at all. However this is a good question.
I suggested a separate database and that implies a separate
datamodel for this one service only.
I am not sure what the best design for such a datamodel would
look like. I guess some averages need to be cached and the
values for the highway-tag of submitted wayIDs be fetched from
the osm-database on collection and stored.
You could then have 2 indice by highway-type and by wayID.
Selecting all meassurements for a wayID should not take too long
but if it does a combined index on wayID and the property that
shows to be the best to separate meassurements that are required
to give an answer and the ones that are not (e.g. by "vehicly-category")
can speed things up.
Such things are the experience you can gather by writing a prototype
and then trying to actually use it.
Marcus
More information about the Routing
mailing list