This is a good time to be thinking about the different uses (or markets) which exist for maps in a printed format, which is the format that the majority of users are likely to relate to. Electronic format can be handled with GPS which is a different strand of interest and is not presently a high priority. QGIS includes GPS features and I will look at these at some stage, as well as the possibility of exporting some data into Google Earth KML files. However the most important priority as of now is the printed formats and I won’t be considering anything in another format until there is a Level 0 map produced for every NZR line in New Zealand.
Smaller scale maps for people such as long distance passenger or excursion travellers who are less interested in the detail, is an important consideration. A way of achieving this is to produce the main map (such as MNL) in an overall smaller scale. The 75 page map is suitable for those who want to find specific locations en route, however for open lines there is considerably less interest than for closed branches where the extra level of detail from the large scale is useful because it is much more difficult to find aspects of the line. A smaller scale map would be likely to omit some of the extra data such as street names and contours that are present in the large detail maps as they are drawn. Because it is much more difficult to control the display of data from other maps (for example, all of the stations in each region are presently in the same map layer), at this point I will have to move to dispensing with global layers except for LINZ layer data that is impractical to localise, and placing all the features and paths that are not directly sourced from LINZ into regional layer files. Probably even into line specific files. Therefore the template files will be updated so that there are sectional templates for these.
So that is where the work will also go in the next week in the two currently in existence regional projects (Canterbury-Westland and Nelson-Marlborough) in reorganising their layers. I am also considering another proposal which is to organise all of the projects on a sectional basis. That is that there will be a specific project for each of the major lines (the folders that are in the root folder of the project as they can be seen on SkyDrive). The regional organisation to date for the projects has been naturally organised this way as it is based around the organisation of the LINZ data layers. However, provided that all of the LINZ data layers are organised in a logical and easy to find way, there is no reason that this constraint should apply to the organisation of the projects and the custom layers. There is no issue with data duplication as the LINZ data layers will be placed into a common repository folder structure that can be accessed by all of the projects. Within each project there will be separate layer groups for the branches and heritage lines which are associated with each of the major line routes. This will enable full control of the displayed data for different lines depending on what sort of printed format is desired.
These questions are the reasons why the NZ Rail Maps project has proceeded slowly to date and why I have ignored requests to produce maps for other regions. There is quite a lot of work in these reorganisations. At a practical level, all of the datasources in each project contain a hard coded file path, and these have to be updated manually when the datasources get moved around on the computer. For example, today I reorganised the Skydrive folder structure to place a folder for each line at the root of the project, which contains the output map files, and a Sources folder in the route, which contains the redistributable layers. This level of reorganisation means 252 path references in the project .qgs file have to be updated with the changed locations (because the project file itself is saved in a slightly different location as well). As the project file is stored in XML format it is simply a matter of opening that in Notepad++ and doing a global find and replace (after making a backup copy of the project file, of course!). Since I also have to change the paths for the fixed layers I may as well create a proper repository structure for these that is easy to follow. This means yet more work. However once these decisions are made and implemented they will be followed for the remaining regions and the extra work isn’t needed. You can see that by piloting these changes over only the two current regions I have saved myself a lot of work later on in changes to other regions if I had pushed ahead and created all of these already.