mc2bsbh - MapCal Template to BSB Template Conversion

[HappySeagull]

I'll mark that!Thanks!that's interesting...I guess in GE they want it to "look right" while in roadmaps,it doesn't matter.

[Netsurfer]

Addendum:
When calculating the scale of the (screenshot) map one also must take care of the ppi (pixel per inch) value of its screen, correct?

For Windows this normally defaults to 96 ppi if not changed by the user.

Gunther

[HamishB]

Originally Posted by Netsurfer

I had a look at the linked script but I do not really understand where all the values in the formula come from?

the GIS software's g.region program supplies things like north, east bounds and region extent.

I have the following values:

• Lat/Lng values of every point of the map
• Lat/Lng for every pixel and its position

Is it possible to calculate the scale from these values?

by definition scale relates distance on the ground to distance you see in front of you.

we know a degree lat is 60 naut miles, and a naut mile is 1852 meters, so there's the distance on the ground half of it.

Windows may say "96" or some value between 72-110 dpi, and maybe your newer monitor gives some hints about it, but really distance in front of you on the screen is (screen resolution / physical size of the screen).

say you have 1280x1024 monitor resolution. Obviously the physical distance between points A and B on a map (measured with a ruler pushed against the screen) will be quite different if you show that on a 7" netbook or a 24" desktop monitor. But the program has no idea about the monitor, and the OS possibly a general idea, if you are lucky..

What software like Inkscape, GIMP, Ghostview, ... do is offer a calibration tool in their setup preferences. They show a graduated line on the screen, you push you ruler up against the screen and adjust until the two match.
Then the program knows the "pixel distance factor". (as long as you don't change monitors or screen resolution after that!)

so it's impossible to do for all users out-of-the-box as it is monitor and resolution specific .. just have to pick a reasonable default and survive on knowing a 1:10,000 map is for a harbor, and a 1:1million map is for the ocean, one is finer than the other, and don't trust the scale number for anything important!

BTW: The screen capture is meant for small areas like a harbour plan/view. Not for large maps. So it is unlikely that the latitude degrees span more than 1 degree at a maximum.

Which latitude value should be taken for the calculation?
The most northward one (if in the Northern hemisphere)? Or the most southward one? Or the one of the center of the map?

center of the map, but for distance on the ground calculation above you might want to use north edge - south edge.

PS: Just to avoid any misunderstandings - Google Maps uses WGS84 and Mercator projection. So I guess nothings else to put to the header, correct?

(ie google maps, not google earth)

Not exactly, they use a bastardized thing which has been dubbed "Google's Spherical Mercator".

[EPSG unofficial reference ID code 900913 (they didn't want to give it an official one as it's a broken mess as far as the geodicists are concerned, but now they caved to popular/practical pressure and gave it one but I don't recall the new number)]

so the earth isn't exactly round, it bulges at the equator. this ellipse is defined with both a major and minor radius. The WGS84 *datum* is defined as using the WGS84 *ellipsoid* (yes, confusing). The WGS84 ellipsoid is defined as follows:

    WGS84 a=6378137.0      rf=298.257223563

+a is the semi-major axis (radius of the earth in meters), +b is the semi-minor axis, +rf is the reciprocal of flattening (1/f), and they all meet with b = a (1 - f).

so for wgs84's ellipsoid b=6356752.314 meters, at 6,357km it's slightly less than +a.

now what Google Maps/Bing Maps/Openstreetmap have done for their map tiles is to pretend that the earth is a sphere, and use WGS84's +a term as the radius. That is the extent of the GoogleMaps--WGS84 connection, they just borrowed one of the constants. This is done to make the calculations a lot simpler, which I guess is the trade off they make for an operation and power bill as big as theirs. expect a couple pixels of distortion over the extent of your monitor- good enough for map directions, not so good for precise cartography post-Napoleon's era.

finally, to relate google/bin/OSM zoom level (z=9-18 in th URL) to map scale, the magic formula is:

scale = (2*radius_earth_a*PI * cos(lat*Degrees2Radians) * PIXELFACT) / (256 * 2^zoom);

(use lat at center of the image)


good luck,
Hamish

[HamishB]

oh yeah, and each individual row of map tiles will have it's own specific map scale. you usually just see a few rows of the 256x256 tiles so it isn't really noticeable, but go far enough & something would have to give, like an out-of-alignment wheel stuttering as you drive along.

[Netsurfer]

Hamish ...

thank you very much for the excellent explanation!

AFAIS it is important that every user knows the pixel per inch (ppi) value of its monitor.
Found a simple to use one here: DPI Calculator / PPI Calculator

For my monitor the result is very accurate.

So here is the million dollar question:
I know about the

• north and south latitude of the image
• height in pixel
• ppi value of the used screen

So assuming that 1 degree lat is 60 naut miles, and a naut mile is 1852 meters, the distance between the north and the south bound of the image can be calculated.

Additionally we know about the height of the image in pixel and how many pixels are a inch/ centimeter. So we can calculate the distance on the screen.

Now all that is left is set both values in relationship to each other.

Or is this too simple?

scale = (2*radius_earth_a*PI * cos(lat*Degrees2Radians) * PIXELFACT) / (256 * 2^zoom);

All values except the 'PIXELFACT' are clear. Which pixel factor is meant?
PPI, Dot Pitch, ...?

Thanks a lot,
Gunther


PS: I wonder how the GE2KAP program is calculating the SC?

[Netsurfer]

OK ..., here is a first test (result).

I calculated the scale with the "simple" method described in my posting above.

The screenshot picture is relatively small: 990px x 550px

OK, there could be some fine-tuning by some pixels but overall I think it is quite usable.

Here is the header file I used for imgkap:

VER/2.0
BSB/NA=Figueira da Foz
    NU=1,RA=990,550,DU=72
KNP/SC=6412,GD=WGS84,PR=MERCATOR,PP=0
    PI=UNKNOWN,SP=UNKNOWN,SK=0.0,TA=90.0
    UN=METERS,SD=UNKNOWN
REF/1,0,0,40.15245681106059,-8.876116275787354
REF/2,990,0,40.15245681106059,-8.854873180389404
REF/3,0,550,40.14343578761962,-8.876116275787354
REF/4,990,550,40.14343578761962,-8.854873180389404
CPH/0.0
PLY/1,40.15245681106059,-8.876116275787354
PLY/2,40.14343578761962,-8.876116275787354
PLY/3,40.14343578761962,-8.854873180389404
PLY/4,40.15245681106059,-8.854873180389404

And that's the final header of the generated kap file:

! 2011 imgkap 1.1 - at 02/07/2011 from FigueiraDaFoz_990_550.png
VER/2.0
BSB/NA=Figueira da Foz
    NU=1,RA=990,550,DU=72
KNP/SC=6412,GD=WGS84,PR=MERCATOR,PP=0
    PI=UNKNOWN,SP=UNKNOWN,SK=0.0,TA=90.0
    UN=METERS,SD=UNKNOWN
REF/1,0,0,40.15245681106059,-8.876116275787354
REF/2,990,0,40.15245681106059,-8.854873180389404
REF/3,0,550,40.14343578761962,-8.876116275787354
REF/4,990,550,40.14343578761962,-8.854873180389404
CPH/0.0
PLY/1,40.15245681106059,-8.876116275787354
PLY/2,40.14343578761962,-8.876116275787354
PLY/3,40.14343578761962,-8.854873180389404
PLY/4,40.15245681106059,-8.854873180389404
OST/1
IFM/7

After the last line the RGB values and the binary data follow.

Gunther

[Netsurfer]

I am still hoping that we'll get the option to simply add and manage georeferenced images (png) as layers with configurable transparency.

Because actually there is no (good) reason to generate kap files from these images ...!

And it would be nearly perfect if these layers could also have "markers" with info windows which may contain some further information and optional links.

So (nearly) everyone will be able to create such overlays within minutes.

Gunther

[HamishB]

Originally Posted by Netsurfer

AFAIS it is important that every user knows the pixel per inch (ppi) value of its monitor.

well, only if you care about scale being exact. In practice you'll burn your particular scale value into the KAP file forever more, and for everyone and everywhere else. It's really designed for paper chart originals, not S-57 ENCs as for electronic sources "scale" loses most of its meaning.

if it is just used to sort the raster chart list on the bottom rectangle bar, then approximate (relative) scale is what mostly matters.

Or is this too simple?
...
I calculated the scale with the "simple" method described in my posting above.

looks good.

All values except the 'PIXELFACT' are clear. Which pixel factor is meant?
PPI, Dot Pitch, ...?

("pixel factor")

it's pixels/meter

you'd need to apply 2.54 cm/inch, 100 cm/meter

The screenshot picture is relatively small: 990px x 550px

looks good.

OK, there could be some fine-tuning by some pixels but overall I think it is quite usable.

note that the source imagery is often observed to be up to 150m out. Google Maps seems much better than Bing in my part of the world, my theory is that they used the streetview car's gps tracks to better align them.

I am still hoping that we'll get the option to simply add and manage georeferenced images (png) as layers with configurable transparency.

i.e. anything the GDAL library can read. note the map projection would have to be identical, or preprocessed first with gdalwarp. It looks great but I worry a little about feature creep.

n.b. that would bypass the BSB encoding patent (for the next two years or so until it expires), but not the Web Map's terms of service.

geotiff support via the GDAL library would be a great start. GeoTiffs allow encoding all sorts of meatadata in the header which could feed the raster info preview mouse-over text.


Hamish