This article assumes you already have the Flex 3 SDK and FlashDevelop 3 installed and working. See my post from two years ago for help.

Compilation Options

There are two ways OpenScales can be compiled. Firstly the source code can be included with your application code. This approach is good for debugging OpenScales and learning how it works. My understanding of the OpenScales LGPL license is that this will make your application also licensed as LGPL (or a compatible license). However I’m not a lawyer so if that aspect is important to you then you will need to take a closer look.

The second way to compile OpenScales is as a library (SWC file). This library can then be linked with your application to produce the final Flash file.

Compiling OpenScales Into a Library

1. Download and install the ExportSWC plugin for Flash Develop.

2. Create a new Flex 3 project with no package name.

3. Check out OpenScales using Subversion into the folder above the project folder. Note that if you use a different location the paths in the rest of this tutorial will need to be adjusted accordingly. I recommend TortoiseSVN if using Windows.

4. Go to Project -> Properties -> Compiler Options. Click on the Additional Compiler Options field and then the small “…” button.

5. Enter:

-namespace http://openscales.org ..\OpenScales-1.1\src\openscales-fx\src\main\flex\META-INF\manifest.xml

Note the hyphen at the start of the line.

6. Click on the Classpaths tab and add the following Classpaths:

..\OpenScales-1.1\src\openscales-core\src\main\flex
..\OpenScales-1.1\src\openscales-fx\src\main\flex
..\OpenScales-1.1\src\openscales-proj4as\src\main\flex
C:\Program Files\FlexSDK\frameworks\libs
C:\Program Files\FlexSDK\frameworks\locale\en_US

then close the dialog window. Note if you copied the Flex 3 SDK to a different location then choose the correct location when adding the libs and locale classpaths.

7. Download GTween, extract the zip file and copy GTween_xx_xx.swc into the lib folder for the project.

8. In the Project tree view right click on the GTween SWC file and choose “Add To Library”. The name will turn blue.

9. In the Project tree expand “libs” and “locale”, right-click on each SWC file in turn and choose “Add To Library”. The names will turn blue.

10. Click on the Build SWC toolbar button to generate the SWC file.

You may get two warnings for the OverviewMap.mxml file, which causes the build to fail. I think this is a bug in FlashDevelop because warnings shouldn’t cause the build to fail, only errors should. However the warnings can be disabled in the compiler options. I don’t know for sure if the Overview Map control is usable because of this.

The generated SWC file will be in the bin subfolder. In FlashDevelop create a new Flex 3 project and copy the OpenScales SWC file into the lib folder, then add it to the library by right-clicking on the name in the Project tree and choosing “Add To Library”. OpenScales can now be used.

Compiling Application Code With OpenScales Code

1. Create a new Flex 3 project with a suitable package name.

2. Check out OpenScales using Subversion into the folder above the project folder. Note that if you use a different location the paths in the rest of this tutorial will need to be adjusted accordingly. I recommend TortoiseSVN if using Windows.

3. Go to Project -> Properties -> Compiler Options. Click on the Additional Compiler Options field and then the small “…” button.

4. Enter:

-namespace http://openscales.org ..\OpenScales-1.1\src\openscales-fx\src\main\flex\META-INF\manifest.xml

Note the hyphen at the start of the line.

5. Click on the Classpaths tab and add the following Classpaths:

..\OpenScales-1.1\src\openscales-core\src\main\flex
..\OpenScales-1.1\src\openscales-fx\src\main\flex
..\OpenScales-1.1\src\openscales-proj4as\src\main\flex


then close the dialog window.

6. Download GTween, extract the zip file and copy GTween_xx_xx.swc into the lib folder for the project.

7. In the Project tree view right click on the GTween SWC file and choose “Add To Library”. The name will turn blue.

Now you can add OpenScales controls to Main.mxml and build a Flex/ActionScript 3 project.

It is possible to add the GTween source code to the project instead of the SWC if needed.

You may get two warnings for the OverviewMap.mxml file, which causes the build to fail. I think this is a bug in FlashDevelop because warnings shouldn’t cause the build to fail, only errors should. However the warnings can be disabled in the compiler options. I don’t know for sure if the Overview Map control is usable because of this.

For completeness my MXML and ActionScript test code follows. Note that I avoided using MXML to create any controls, instead preferring to use ActionScript. This is just a personal preference.

Example Main.mxml file:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:os="http://openscales.org" layout="horizontal" horizontalAlign="left"
backgroundColor="#FFFFFF" backgroundGradientColors="[#FFFFFF, #FFFFFF]"
paddingTop="0" paddingLeft="0" paddingRight="0" paddingBottom="0"
creationComplete="OSMap.main();">
</mx:Application>

Example OSMap.as file:

package com.britishideas
{
  import mx.controls.*;
  import mx.core.*;
  import mx.events.FlexEvent;
  import flash.events.*;
  import flash.utils.*;
  import flash.display.Sprite;
  import org.openscales.fx.FxMap;
  import org.openscales.core.Map;
  import org.openscales.core.layer.osm.Mapnik;
  import org.openscales.core.handler.mouse.DragHandler;
  import org.openscales.core.handler.mouse.WheelHandler;
  import org.openscales.core.control.PanZoomBar;

  public class OSMap
  {
    private static var map:FxMap;
    private static var mxmlApp:Application;
    private static var osmap:Map;

    public function OSMap()
    {
    }

    public static function main():void
    {
      mxmlApp = Application(Application.application);
      map = new FxMap();
      map.width = 840;
      map.height = 840;
      map.zoom = 10;
      mxmlApp.addChild(map);
      map.addEventListener(FlexEvent.CREATION_COMPLETE, MapCreated);
    }

    private static function MapCreated(e:FlexEvent):void
    {
      osmap = map.map;
      var MapnikLayer:Mapnik = new Mapnik("Mapnik", true);
      osmap.addLayer(MapnikLayer);
      var dragHandler:DragHandler = new DragHandler(osmap, true);
      var wheelHandler:WheelHandler = new WheelHandler(osmap, true);
      osmap.zoom = 10;
      osmap.addControl(new PanZoomBar());
    }
  }
}

Map Scales

A map scale looks something like 1:1000. This means that for every 1 inch on the map there are 1000 inches in the real world. The units don’t matter, for example it also means that 1 meter on the map is 1000 meters in the real world. The value 1000 shown in this example is called the Scale Denominator.

Maps (in the context of this discussion) are generated using pixels. This is true even if printing because ultimately the printer has to print the pixels onto the paper (assuming a raster output). At low resolutions the pixels will be easily seen. Not so at high resolutions.

It is therefore useful for us to know the size of a pixel in meters. If we know this then we can work out the map scale and set the map scale.

Universal Transverse Mercator

The world is round and not flat (no comments on this please!) and therefore we need a way of converting a section of it onto a flat piece of paper. The method of converting a curved section of the world to a flat representation is called the projection. There are many different projections to choose from and software available to convert data using the different projections. Universal Transverse Mercator (UTM) is a useful projection because it’s units are in meters. Typical map data uses latitude and longitude in degrees, which are difficult to use in calculations. However meters are much easier to work with.

The first step therefore is to get the bounding box of your map in degrees and convert it to meters in UTM. Mapnik can also do this for you using the projection class.

A bounding box is defined by the two coordinates that locate two opposite corners of the rectangle which defines the area in the map. The UTM zone is not needed, and we will assume the map area fits within a single UTM zone.

Maps For Screens

We assume that a pixel on a screen is 0.28mm on each side. This may or may not be true in reality, but it’s called the “standardized rendering pixel size” and is defined in the OpenGIS Styled Layer Descriptor (SLD) Implementation Specification. This assumption is made because software typically doesn’t know the pixel size on a screen and it’s a reasonable assumption. If the actual pixel size is known then it should be used. 0.28mm = 0.00028 m

We know the width of the area we wish to draw in meters from the UTM bounding box. We will call this map_realwidth_m. We also know the width of the map in pixels, because we choose that based on our requirements for the map. For example if the map is to go on a web page then the maximum width is probably something like 800px. We will call that image_width_px. Therefore:

scale_denominator = map_realwidth_m / (image_width_px x 0.00028)

The scale denominator is simply the ratio of the real world area width to the map width.

To summarize, for a bounding box in UTM coordinates and a given map width in pixels you can now calculate the scale of the map. However by rearranging the formula a UTM bounding box width can be calculated from a specific map scale and image width in pixels. By choosing a coordinate for the center of the map or one corner the UTM bounding box can be fixed.

Here is an example.  The width of the UTM bounding box is 1600 meters. The image width is 800px. Therefore:

scale_denominator = 1600 / (800 x 0.00028) = 7143.
Map scale is 1:7143.

For a map scale of 1:2000 and an image width of 800px, the UTM bounding box width will be:

map_realwidth_m = 2000 x (800 x 0.00028) = 448 meters

Maps For Printing

Generating maps for printing is the same as for a screen except the resolution is different. For example a pixel size of 0.00028m corresponds to a resolution of approximately 90.7 Pixels Per Inch (PPI). This is a relatively low resolution and will likely appear quite poor when printed. Printing has a much better resolution than a screen. For example printing an 8″ x 10″ map might need 300 PPI to get enough detail. Large posters might be printed at 150 PPI. Note that sometimes PPI is referred to as Dots Per Inch (DPI) although DPI is specifically related to printing whereas PPI is more generic.

The first step in creating a map for printing is to determine the PPI to use. This is defined by the size of the print and the printer. For the examples that follow we will use 300 PPI, but any value can be used.

Next we need to work out the pixel size for the resolution.

300 PPI = 1 / 300 inches per pixel. 1/300 x 25.4mm/inch = 0.0846mm = 0.000085 meters

Now we need to work out the width of the map in pixels. For 300 PPI and a width of 7.5 inches we get:

image_width_px = 300 x 7.5 = 2250px

We can now put these values into the map scale formula to calculate the scale from the UTM bounding box, or calculate the UTM bounding box width from the scale. For a UTM bounding box that is 1600 meters wide:

scale_denominator = 1600 / (2250 x 0.000085) = 8366
Map scale is 1:8366

XML Stylesheet

The Mapnik XML stylesheet tells Mapnik what to draw for different map scales. The rules are enabled by specifying a maximum and minimum scale denominator.

When creating maps for printing it is important to remember that internally Mapnik is assuming the map is for the screen and therefore has a different scale denominator. To get the scale denominator which Mapnik thinks is being used:

# zoom to bounding box then…
internal_scale_denom = mymap.scale_denominator()

Use this value when constructing the rules for the XML stylesheet.

Notes

If you tell Mapnik to render a specific UTM bounding box to an image of a specific dimensions then it will expand the bounding box in one direction so it has the same proportions as the image to be created. This can change the width of the UTM bounding box and therefore the scale calculation. The solution is to base any scale calculations off the actual bounding box. Mapnik can give you the values by calling the envelope() function on the map object.

The scale is an approximation and might only be valid for the center of the map. The larger the area represented in the map the more distortion there will be and therefore less accuracy when using the scale.

OpenStreetMap uses zoom levels numbered one to 18. This file shows the relationship between the zoom levels and the scale denominators.

Get JOSM

First download the current version of JOSM, which is a Java based editor. You will also need to install Java 1.5. You can also read more about JOSM here and here.

Start JOSM. On the command line this is something like:

java -jar -Xmx512M josm-latest.jar

There are some JOSM plugins that I think are essential, and here is how to add them:

• Start JOSM
•  Go to Edit -> Preferences
• Click on the plugins tab (looks like a wall socket/outlet)
• Click on “Download List”
• Check/tick the following: utilsplugin, validator, waydownloader
• Click on “OK”
• Restart JOSM

Next you need to tell JOSM your OpenStreetMap username and password.

• Go to Edit ->Preferences
• Click on the connection settings tab (looks like a planet)
• Enter your email address and password
• Click on “OK”

Next install the WMS Plugin for JOSM that will allow you to view Yahoo satellite images.

Download a Section of the Map

Next you will want to download the part of the map that covers your local area.

• Click on the Download From OSM toolbar button
• Check/tick “Download as a new layer”
• Drag the map with the right mouse button, zoom with the mouse wheel or Ctrl + arrow keys
• Drag a box with the left mouse button to select an area to download. Keep it small for now.
• Click on “OK” and wait a bit. It could take a few minutes so don’t give up too quickly

You will now be looking at a black screen with lots of lines on it. Zoom in to a few streets using the magnifying glass tool on the toolbar.

Get the Satellite Images

The next step is to get the satellite images so we can see how the streets compare with the real world.

• Go to  WMS -> Yahoo Sat (may have a slightly different name depending on the JOSM version)

At the top right under the Layers heading a new layer should appear called “Yahoo Sat” or something like that. Wait a bit and the images should start to appear.

Edit the Map

It’s now time to start editing. It should be clear if a street is not aligned with the Yahoo images. If it isn’t then you can click on the Select tool on the toolbar and start dragging the nodes (small yellow boxes). Position a road over where it is in the satellite image.

Upload!

Once you have fixed a few roads click on the Upload to OSM toolbar button.

• Enter a description for the change
• Click on “Upload Changes”

Once complete you can go to your OSM account page and view your edits. The URL is http://www.openstreetmap.org/user/myusername/edits. Replace “myusername” with your user name. You should see your first edit!

After waiting a few minutes your changes should start to appear on the map. Mapnik (the default renderer) renders the lower zoom levels more frequently, so you should see your changes appear in stages and only in some zoom levels. After a day or so all the lower zoom levels should show your changes.

Some Notes

The Yahoo satellite images are not always in the right place, but it seems from my experience they are pretty good. However this is something to keep in mind.

Along with fixing streets, it’s also possible to add in schools, malls, hospitals, businesses, rivers, streams, parks, etc. all by using the satellite images. There is plenty to do!