Accessiblity to tourists

[HarelM]

I'm not sure how relevant the feature is, but currently this map is not accessible to tourists.
making English tiles or English labels tiles would help in this direction.

[valleyofdawn]

You may need to separate labels from the rest, like they do in http://toposm.com. this though makes it harder to use the tileserver in 3rd party applications.

[HarelM]

We can create two sets of tiles, one in English and one in Hebrew.
The site can allow the user to change between the two.

[ATGardner]

I have made a version of the hiking rule set with English label, to create my INT offline map file in English. I will make a PR with it (I will first merge it with the recent changes of the Hebrew rules from the master).
I hope I will have time to do it tonight, or tomorrow morning.
But creating the entire map again in English takes a lot of time.

[HarelM]

I know this may seen a lot to ask but adding an English rules file will probably make it harder for us to maintain the current rules file as we will need to remember to add every change to both files.
Do you think you can create a python script to do this migration automatically?

[ATGardner]

I understand the problem. I'll look into it, but that won't happen before I get back from my vacation.
Is there a way in Maperitive to use several rule files? Maybe it can be split into one main file, and then two different files just for the text labels. If this is not possible, I guess some migration script is the way to go.

Do you prefer I PR the en rules, just so people can have a look at them, or should I hold off anyway?

[HarelM]

I don't think someone is anxious to get the English rules file so I wouldn't hurry with a PR.
It would be a waste if it's not in a source control somewhere though so at least commit it to your repository....

[zstadler]

I like the idea of having a Maperipy script create the name tag to be used by Maperitive in order to enable easy language switching.

Perhaps the script can be configured to take a sequence of languages in descending order of priority. For example, the "en;he;_" language sequence will direct the script to take the English name tag, if it exists, otherwise, the Hebrew name tag, if it exists, or else, take the name tag, it it exists.

This idea is based on the work of the Multilingual Map Test. Unfortunately, this site is currently not working.

By the way, in order to avoid conflicts with existing tags, we can start using our own tag namespace, such as maperitive:name or ihm:name.

[zstadler]

@HarelM Do you have a preference for where to store the English tiles for the two maps? I suppose the map language will change when changing the interface language.

[HarelM]

Ideally I would say the the tiles should be stored in a folder with a language code (i.e. /he/tiles/... /en-US/tiles/...) but I know that changing the current tiles folder is problematic.
Maybe we can temporary create a symlink to Hebrew tiles folder from the current tiles folder until a time where all the apps that uses us will get updated...?
Regardless I would need to change the tiles layer address when changing a language, which might prove difficult since once a layer is created I can't really change this property, but that doesn't really concern you, I agree it would a good user experience (I think, unless you prefer English site buttons with Hebrew tiles...) to change the language of the map when changing the language of the site.

[zstadler]

With all respect to structure, and you know I have, I have greater respect to backward compatibility and avoiding disruptions to users. In short, I'd rather not move the existing tiles, as many people and applications use the current paths.

For the English tiles, I thought of using Tiles.en and mtbTiles.en. By the way, I'm also going to keep Hebrew as the default language in the Map code.

Instead of changing the definition of existing layers, perhaps we may have 2 layers for each map - one for every language. Can the layers UI avoid showing a layer without removing its definition?

[HarelM]

Everything is possible :-). Let me know when you have a working example and I'll see if I can play around and see how it works.
I don't like the tiles.en name, something about it just doesn't feel right - probably the fact that a . is not a character I would expect to see in a site address or in a name of a folder, but that might be just me being old school.
Why not maintain the current address as a link to the new address until we decide to change it?
I think it'll be much more elegant.
We can also decide that we keep the current address as the "default" so we can link the default to whatever we think should be the default and create the relevant folders with the relevant data.
in terms of folders and address it should be either en/tiles/{z}... or tiles/en/{z}... folders will be translated to address and I think this is the appropriate address, also in terms of RESTfull protocol.

[zstadler]

I'm OK with en/Tiles/{z}/... and en/mtbTiles/{z}/....

If we use Tiles/en then en and the standard zoom levels would be at the same level.

We can create a junction/symbolic link for use by the Site's code.

IMO and experience, elegance is not a good justification for inflicting incompatibility on users by removing the current addresses. Each user must feel he/she gets something for the price of incompatibility.

[HarelM]

We can keep the current addresses as our definition of "defalt" tiles. Current address /tiles will be linked (not by the user but by us) to /he/tiles. If we decide to change the default it is up to us.
This will allow us a migration process if we choose to do one.
The tile generation folder will have the right prefix folder and elegance will be achieved in the tile creation process, fair enough?

[zstadler]

Actually, all tile directories are virtual directories in IIS. There is no need for creating any links in the server's file system.

As for the map generation process, I'll use a slight modification of your suggestion and rename the "Site" directory to "Hebrew" and create the English tiles under the "English" directory.

[HarelM]

Great! let me know when I can start playing with it.