Re: [OSRM-talk] [API] Role of profile

[Daniel Patterson]

Hi Mateusz,

  The  in the URL is an unused string.  It's there for future 
compatibility if we ever add multiple-profile support to OSRM, but osrm-routed 
does not look at it currently, other than to ensure that it's there.

  Quite a few people use it as a reverse-proxy filtering token - run a reverse 
proxy with multiple osrm-routed instances behind it, and forward requests to 
the appropriate backend based on the contents of the "profile" field.  It works 
quite well.

daniel

> On Apr 25, 2017, at 12:37 PM, Mateusz Loskot  wrote:
> 
> Hi,
> 
> I'm familiar with role of profile in the OSRM processing flow
> as well as descriptions regarding profile and {profile} parameter
> in the HTTP API docs.
> 
> Still. I'm not entirely clear about the profile role in the HTTP API URLs.
> 
> My current understanding is this:
> 
> 1. profile is actively used during extraction phase of data processing
> 2. user can feed extraction with any custom profile as long as it is
> valid for OSRM
> 3. generated .osrm package corresponds to single profile used during 
> processign
> 3. once data extracted and contracted, and complete multi-file .osrm package
> is ready, profile is not used
> 4. osrm-routed serves routing per single .osrm package, so single profile too.
> 
> When requesting osrm-route, I noticed
> * custom profile is not referenced anywhere
> * actually, profile seems not used
> 
> For example, I have simplistic .osrm package sample
> extracted using custom xxx profile and osrm-routed at
> http://localhost:5000, and both requests
> return the same response valid for the sample data
> 
> route/v1/car/30,20;30,15
> route/v1/xxx/30,20;30,15
> 
> in fact, any {profile} parameter works
> 
> /route/v1/nosuchprofile/30,20;30,15
> 
> Now, if I use libosrm API, neither engine config nor any of *Parameters
> require specification of profile.
> 
> These observations as well as the fact that osrm-routed
> serves single .osrm package, so no profile ambiguity is actually
> possible, make me think the {profile} parameter in URLs is unused and 
> redundant.
> 
> Is that correct?
> 
> Best regards
> -- 
> Mateusz Loskot, http://mateusz.loskot.net
> 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk


___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSRM-talk] [API] Role of profile

[Mateusz Loskot]

Hi,

I'm familiar with role of profile in the OSRM processing flow
as well as descriptions regarding profile and {profile} parameter
in the HTTP API docs.

Still. I'm not entirely clear about the profile role in the HTTP API URLs.

My current understanding is this:

1. profile is actively used during extraction phase of data processing
2. user can feed extraction with any custom profile as long as it is
valid for OSRM
3. generated .osrm package corresponds to single profile used during processign
3. once data extracted and contracted, and complete multi-file .osrm package
is ready, profile is not used
4. osrm-routed serves routing per single .osrm package, so single profile too.

When requesting osrm-route, I noticed
* custom profile is not referenced anywhere
* actually, profile seems not used

For example, I have simplistic .osrm package sample
extracted using custom xxx profile and osrm-routed at
http://localhost:5000, and both requests
return the same response valid for the sample data

route/v1/car/30,20;30,15
route/v1/xxx/30,20;30,15

in fact, any {profile} parameter works

/route/v1/nosuchprofile/30,20;30,15

Now, if I use libosrm API, neither engine config nor any of *Parameters
require specification of profile.

These observations as well as the fact that osrm-routed
serves single .osrm package, so no profile ambiguity is actually
possible, make me think the {profile} parameter in URLs is unused and redundant.

Is that correct?

Best regards
-- 
Mateusz Loskot, http://mateusz.loskot.net

___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk