Accessiblity to tourists about map HOT 15 CLOSED

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.

from map.

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.

from map.

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.

from map.

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?

from map.

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?

from map.

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....

from map.

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.

from map.

@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.

from map.

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.

from map.

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?

from map.

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.

from map.

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.

from map.

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?

from map.

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.

from map.

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

from map.