Main vs dedicated profiles about brouter-profiles

[poutnikl]

I agree my current policy of updates of profile folders is for historical reasons rather weird. I may rewrite the batch file to automatically make copies to mainprofiles. I rather avoid symlinks as it may cause sync troubles.

Linux Bash script generator is for now rather nice to have topic on future features list, as I am better in Windows batch files than in Bash scripts.

Until now, mainprofiles generation was rather avoided not to create impression foot/car profiles were updated as well.

[poutnikl]

Well, you are right. I was focused mainly on users.
I will consider to create a developer wiki page.

About issues, development and FR related to profile template, the best is to put them to template development repos.

To Brouter-profiles repo belong topics about end profile deployment policy, generation of new profiles from templates,
special requests not possibly done with regular template, auxiliary files questions etc.

[poutnikl]

Initial versions:
https://github.com/poutnikl/Brouter-profiles/wiki/Contribution-tips
https://github.com/poutnikl/Brouter-profiles/wiki/Profile-developer-notes

[poutnikl]

You are generally right these profile should match,
IF they are generated from the same profile template. The template version should be included in the profile header comments.
Main and dedicated profiles are generated by the separated script runs
and manually included.
It may happen the runs used different template version.

So the question should rather be, what is the difference between template versions

This should be mentioned in the template history, or in the template repository(not handy to investigate now, being on phone access).

[Phyks]

You are generally right these profile should match, IF they are generated from the same profile template.

Ok!

This is the issue I guess, MainProfiles are version 2.5.6 BETA. BikeProfiles folder are 2.6.*.

Main and dedicated profiles are generated by the separated script runs and manually included.

Ok! That does not seem super easy to maintain, having a script to generate the content of this repo directly might be useful as an improvement. So, the conclusion is that user eager to get the latest version should build from the dedicated sub-repositories, if I understood correctly.

As a side note, (as a newcomer) I feel that additional documentation on this might be a nice addition. It is a bit confusing when arriving first to this repo to find out which version of the templates is expected to be the most updated. I can write a PR for this if you think that's worth adding to the README.

Thanks!

[poutnikl]

In fact, it is easy. All the development is done in respective github repositories for car/bike/hiking profile templates.

The Brouter profiles repository serves more or less as a featured cloud storage with history.
Users are not supposed to do any actions but download presented profiles and read the wiki.
Http://GitHub.com/poutnikl/Brouter-profiles/wiki

The README file is intentionally kept with minimal content, merely just pointing to the repository wiki(*) and related projects. I may add version info to the README as a quick orientation

(*) Therefore independent file and wiki repositories can be updated independently.

I generate new versions of the end user profiles only occasionally.
The script runs locally, with parameters to generate either full set of car/bike/foot profiles, either selected subset for all-aka mainprofiles. It downloads the master version of template and by the simple string substitution creates locally the profiles.(*)
Then by git command, the remote GitHub profile repository is updated.

(*) This can be done by an advanced user as well, Regular it sets need not to bother.

[poutnikl]

So, the conclusion is that user eager to get the latest version should build from the dedicated sub-repositories, if I understood correctly

Rather, either to download the master ( or even develop branch) template manually and manually tweak template to get particular profile or their custom one,

Either run the batch ( launching legend in the file or when run without parameters) to generate the profile set locally.

As not all template master branch updates are necessarily reflected by new profile versiona generation.

[Phyks]

The Brouter profiles repository serves more or less as a featured cloud storage with history.
Users are not supposed to do any actions but download presented profiles and read the wiki.
Http://GitHub.com/poutnikl/Brouter-profiles/wiki

For sure, for users. But developpers, they might want to have a quick intro with getting started and orientations :)

In my particular case, I was setting up a BRouter instance with a few modifications and was trying to get an overview of available BRouter profiles around there with their specifities. Very soon, it is easy to get completely overwhelmed by the quantity of profiles around with slight differences :)

Same thing stands for issues. I was willing to open an issue (poutnikl/Trekking-Poutnik#23) and did not know whether it should go on the BRouter-profiles repo (where I got the files from initially) or on the Trekking-profiles repo (where the development is actually made).

The README file is intentionally kept with minimal content, merely just pointing to the repository wiki(*) and related projects. I may add version info to the README as a quick orientation

Sure. The wiki has a lot of details about the profiles and their use case, that's really amazing (from a user perspective)! But finding developper-oriented infos is a bit difficult (basically what you told me in this issue) :) Thanks a lot for the explanations!

[poutnikl]

@Phyks The bash script sedbatch, running in termux/Android, already works with git, producing zipped profile packages in my BRouter data folder. With a command modifier parameter, it could make the respective commit and push to the Github.

To be implemented. :-) But as the repository is not updated very often, it is not a big deal to commit/push profiles manually.