Linear maps

by Morten 12. November 2007 03:42

The Map Room blogs about San Francisco's new public transport maps that will employ more "straight lines", also covered more in depth here. I find these sort of map abstractions really interesting, so I thought I would chip in with a couple of similar "straight-lines" public transport maps from Copenhagen. It must take a good degree of ingenuity to weigh accuracy with simplicity.

The first one shows the most used map for the network using straight lines as much as possible. You can still clearly see the "five-finger plan" that had been used for city planning for many years by expanding out in "fingers" and allow for greener less dense areas in between. Click the image for a larger view:

The second shows a much more dense map (usually used on a larger poster) which also shows some of the major bus routes. This map is much more geographically correct with a slight grey outline of the land behind it. It still uses straight lines to simplify the map (click for larger view):

There's an even simpler version, where the map is far from geographically correct, but instead shows the network and connections as a set of mostly horizontal lines. This map is mostly used inside the train, so at this point you (hopefully) already know where you are headed and don't need any geographic resemblence. Therefore this "map" only shows which stations the train lines stops at/skips and where they connect to each other,and it fits nicely over the door :-) (unfortunately this was the best picture I could find):

Tags:

Comments working again

by Morten 17. October 2007 02:55

Thanks to Al for pointing out that my comments section was failing with JavaScript errors. Apparently the blowery http compressor that this site is using was messing up the embedded ASP.NET JavaScripts so they return empty script files. Fortunately a workaround exists for this.

So if you meant to comment about one of the screw-ups in my recent blogposts, here's your chance.

Tags:

Off topic

Huge wind turbines in Virtual Earth

by Morten 16. October 2007 03:31

Since today is Blog Action Day and the topic is the environment, I thought I would share this amazing birds eye view of one of the 2mW windmills in the offshore windfarm "Middelgrunden" just off the coast of Copenhagen that was published last week. I've knew these windmills were BIG, but looking from the peer it's hard to tell how big they really are. The boat next to it really gives a sense of its size. I can't even begin to imagine how big the 5mW mills they make these days are... 


There are 20 of these mills, all together producing 3% of Copenhagens total electricity consumption. Around 20% of Denmarks electricity comes from windmills.

Warning... bad joke coming up: Now you know why I moved to Sunny California - The weather really "blows" in Denmark :-)

 

Tags:

Off topic | Virtual Earth

New Virtual Earth release

by Morten 16. October 2007 02:37

I just visited http://maps.live.com and it looks like they finally put the new release out there. A revamped design and Birds Eye View imagery inside the 3D viewer. You can now also create animations using your collections.

Nyhavn, Copenhagen - A place I missed a lot this summer

Another new feature is the new "Create model" button in the collection editor when you are in 3D mode. Using it will prompt you to download "3dvia" enabling you to model your own buildings and insert them into VE. It looks somewhat similar to SketchUp used for the same thing in Google Earth. A neat feature is that you get the map as a background to assist you in your modelling, and comes with a bunch of default textures as well:

Tags:

GIS | Virtual Earth

Accurate distance calculations in UTM projections

by Morten 14. October 2007 00:54

Recently a friend of mine asked me what projection would be the best to create point-buffer circles. All map projections adds distortion so you rarely end up with a circle. If you’re lucky, you’ll have an ellipse but often they get even more complex than this. In many cases a “normal” circle is sufficient for accuracy, but still it got me thinking how I would do this 100% accurate. There are many approaches to this, fx. creating a new projection for each point, do the math in spherical coordinate systems etc, but none of them are completely trivial.

The UTM projection is one of the most commonly used projections. It’s fairly accurate to measure from point to point within small distances and close to the meridian, so this post is based on that. Most of the math here can also be applies to Mercator, where the scale reductions are applied to Y instead of X.

The Mercator projection is created by projecting the globe onto a cylinder whose center follows the Earth’s rotation axis. The Transverse Mercator is basically a "tilted" cylinder parallel to equator. Along the line that the cylinder "touches" the surface the distortion is 0, and increasing away from it in the east/west direction. There is no distortion in the North/South direction. The Universal Transverse Mercator is slightly smaller than the globe, so it will intersect the surface two places. This also ensures that the distortion between and around these two lines are minimal. Along the meridian (the center of the two lines) the distortion for the UTM projection is 0.9996, meaning that this is the amount you have to reduce an infinitely small line in the east/west direction (For Mercator this is normally 1 along Equator). As you move away from the meridian, the scale factor increases up toward infinity. Normally UTM projections are used close to the meridian, and every time you get too far east/west, you would switch to use a new UTM projection. That’s why The Earth is divided into 60 UTM ‘zones’, one for each 6 degrees. Often for practical reasons you might want to use a UTM zone even though it’s outside its defined usage area. Here you have to be specifically careful when measuring distances. For example, Denmark is covered by zone 32 and 33, but it’s common to only use zone 32 which means that distance calculations at the east end can be very inaccurate without applying a scale reduction.

Warning: The following contains a lot of math. You can skip to the bottom and download a C# class that does all the calculations for you.

The scale factor SR(x) for any given point at distance 'x' from the meridian is given by:

Since this is the scale reduction at a point, we need to sum up all of these values along a line to find the correct distance, thus the east/west distance from e1 to e0 (expressed in distance from the meridian) becomes an integral expression:

To this you need to add the north/south distance using the well-known Euclidean distance formula.

For atypical UTM using WGS84 ellipsoid and a 500000m false easting it becomes:

If you haven’t refreshed your integral math lately, or just want to write this in pure code, one can also write the expression as:

Where m is the scalefactor at the meridian, r is the earth radius and e1 and e0 have the false easting subtracted.

Often we can do with an approximate value by using the scale reduction between the start and end point. This should only be used on distances <1km in easting because it gets very inaccurate for greater distances.

Simpson’s Rule

One can also use Simpson’s rule for calculating the integral solution. My tests showed it’s a very accurate approximation for this type of integral usually giving millimeter accuracy. It’s defined as:

I performed a few performance tests for 10 million calculations using all four methods for finding a distance in a UTM projection. Below is the processing time for each method:

Euclidean 4.38 s
Average / Linear 4.49 s
Simpsons 6.94 s
Integral 9.26 s

Bottom line of this: If you want performance and distance is small use the averaging method, if you want accuracy, go with the Integral method, or if you want both, use the Simpsons approach.

Distance calculation - example

start point : { E=400,000 ; N=6,100,000 }

end point : { E=600,000 ; N=6,250,000 }

  • Distance using Simpsons rule: 249,942.5569m (error: 0.0003m)
  • Distance with approximate scale reduction: 249936.0046m (error: 6.54m)
  • Distance without scale reduction: 250,000m (error=57.46m)
Where is scale reduction=1?

Solving SR(x) =1 gives us the distance from the meridian where the scale reduction is exactly 1:

Area calculation To calculate the area of a polygon, apply the scale reduction to the line segments and then calculate the area as you normally would.Creating perfect circles

To create a circle with a fixed radius taking scale reduction into account will give you an irregular shape in the projection. You can use the approximate method (using center as scale factor) which will give you an ellipse since the scale factor for x is constant in this case. The formula for approximate circle becomes r2=(SR*x)2+y2 where SR is the scale reduction at the center of the circle.

For "accurate" circles SR becomes dependent on X. To find this solution you need to isolate e1 from the above equations to find the scale corrected distance. My math is too rusty to figure that one out yet, but if you know, feel free to post it in the comments.

You can download a C# class that performs all four types of distance calculations here.

Tags:

GIS | Spatial References

Visual Studio 2008 JavaScript Intellisense - Take Two

by Morten 10. October 2007 05:36

...Not for namespaces either.

We all know that global variables in JavaScript API’s are bad (although they are usually OK in application-specific contexts). So therefore the solution is to create a namespace and put all your objects inside that. That way you only end up with one global, the name of the “root” namespace. You should choose a root name that probably isn’t used by anyone else, like your company name or similar.

With the Microsoft AJAX Clientside Library, Microsoft gave us registerNamespace for this thing, like for instance:

Type.registerNamespace('myCompany.Utility.Math');
myCompany.Utility.Math.Calculator = function() { }
myCompany.Utility.Math.Calculator.prototype = {
 add : function(a,b) { return a+b; }
}
myCompany.Utility.Math.Calculator.registerClass('myCompany.Utility.Math.Calculator');

Basically what Type.registerNamespace does is creating a set of objects:

myCompany = {};
myCompany.Utility = {};
myCompany.Utility.Math = {};

There's is just one problem to this. Visual Studio 2008’s intellisense is not evaluating the result of Type.registerNamespace, and thus, never realizes that those three objects exist. The result is that you don’t get any intellisense on your namespaced objects. Bummer! The workaround is either to create the namespaces yourself (like above) before calling Type.registerNamespace, or create aliases for the classes (which would re-introduce the globals we were trying to get rid of in the first place).

Of course I considered this to be a bug, and as I mentioned at the end of my previous post there was a problem with using namespaces and JavaScript Intellisense in Visual Studio 2008, that I had submitted a bug report for.

I was surprised how quickly they investigated and escalated the issue, but my biggest surprise was the result, which is pretty much this:

We are not going to support the pattern we told you to use until version 20xx.

OK, maybe a bit over-dramatized but still... It's funny because they are actually able to give me full intellisense for the namespaced objects in the MS AJAX Sys.* namespace (but they probably hardcoded that in there ;-)

With this and the fact that javascript files included by webcontrols are not intellisensed either, I’ve come to the conclusion that the hyped and long awaited JavaScript Intellisense in Orcas is pretty much useless. What do you think?

Tags:

Visual Studio 2008 JavaScript Intellisense…

by Morten 3. October 2007 03:23

 …well maybe not for webcontrol users.

One of the most spoken-of features of Visual Studio 2008/Orcas is the new JavaScript Intellisense that helps the client-side developer. I’m very excited about this new feature, and put a lot of effort in documenting my JavaScript with code summaries so that I will get the full benefit when VS2008 ships.

I have been struggling to get this to work with some custom controls that emit JavaScript into the page. The JavaScript is fully documented and each file header references other assembly-embedded JavaScript files, just like the documentation tells me to do it. The problem was that I was getting no Intellisense at all for these scripts, unless I manually inserted them into the page. I also made sure that these commented JavaScript files (I also have compressed/stripped scripts embedded) of these scripts was actually registered during DesignMode.

I was reading a blog-post the other day stating that Intellisense is provided for scripts that are included in the page either as a ScriptReference with the ScriptManager, or as a normal HTML script tag in the page. My controls did just that during the PreRender events.  I emailed one of the bloggers about this, and guess what… this is not supported. If you drag a webcontrol onto the page that emits JavaScripts to the page, you are NOT getting Intellisense for those JavaScripts. So much for building a fully documented JavaScript API.

The reason is performance and security. For once they don’t want to execute user code on the client by rendering the control. But hey wait… isn’t that what is already happening in design time? The controls are rendered with specific design time layout, thus executing user code. OK VS is not doing it in the code editor but in the designer, but what's the difference from a security standpoint? Or could we at least get to allow certain assemblies we trust to do this? With regards to performance, I would think that either you want Jscript Intellisense or not, and if you want performance, you would just go and disable the Jscript Intellisense. They also seem to have nailed this one pretty well with JScript Intellisense being generated in the background while you're coding.

So the proposed workaround is to manually add a ScriptReference to each script using a ScriptManager. There are just two problems to that:

  • You rarely know the full name of the embedded script, and using Reflector to find is often a violation to the EULA’s, and furthermore the name or scripts might change with each release/service pack. -not to mention that it's not very user friendly.
  • Secondly, who says I even have a ScriptManager or want one on the page? Partial Postbacks have longer page life cycles and transmit a lot more data than callbacks, so I might just want to stick with the good old lightweight callback model, or I might not even need any AJAX functionality at all.

The funny thing is that the reply I got from Microsoft started out with saying that they get this question a lot, so there obviously is a demand for it.

I would have to wait 3+ more years for the next Visual Studio release, to harvest the benefit of all my code summaries... '-(

I actually found this other bug trying to get this thing above to work, and at least that is getting some attention. So before you start playing with JString Intellisense in beta2, don't put your classes inside namespaces.

Tags:

JavaScript

Tools I use for JavaScript and AJAX development

by Morten 5. August 2007 00:11

Below is a list of some of my most used features in various web developer tools. The tools can do so much more than I described here. Many of the features are somewhat hidden, so perhaps there’s a few things you might find useful too.

Feel free to share any of your favorite features in a JS and AJAX tool in the comment section below.

Microsoft’s Visual Studio.NET

The tool I use by far the most is Microsoft’s Visual Studio.NET 2005. Its script debugging features far surpasses anything I’ve seen in any other tool. The downside is that this only works for Internet Explorer. What I wouldn’t give for this to work with FireFox too.

The debugging experience is as good as the debugging in a .NET application. You get breakpoints, watches, object inspection and manipulation, step-into/over and so on.

This feature is somewhat hidden, because you need to go through a few hidden steps to enable it (this will change with VS2008).

First you need to enable script debugging in Internet Explorer. Go to internet options, and uncheck “Disable script debugging (Internet Explorer)”.

Then go to “View – Script Debugger – Open” and select a running instance of Visual Studio .NET.

In Visual Studio, go to “Debug – Windows – Script Explorer”. This will bring up the window with the loaded page and scripts. Double-click any of the files in the script explorer to open it and set breakpoints, create watches, inspect objects etc. Open the “Immediate window” to execute any JavaScript you enter. Note that these features only are available while you are at a breakpoint.

A little quirk compared to debugging a .NET application is that you can only hover the mouse on the root object, and not on its sub properties. The workaround is to select the object to get its value, as shown above. The good thing is that this even works on methods, so if you select an object, its method and the ending enclosing parentheses, the tooltip will show you the returned value from that method.

If you are developing a web application in VS.NET and run it in debug more, VS.NET will automatically attach to the browser process if you have enabled script debugging.

FireBug

My favorite tool for debugging JavaScript in FireFox is FireBug. It’s the Swiss army knife of web development in FF. One of the cool features that a colleague of mine brought to my attention was a neat little feature for tracking all events that happen on a selected DOM element. This is great for analyzing which events are available for listen for, see the order that events are fired etc.

To use this feature, choose the HTML tab and browser to the element you want to track. Right-click it and select “Log events”.

Switch to the Console tab and try moving the mouse over the element and you will see a continuous output of all events occurring on the element:

You can also inspect the properties of each event by clicking them:

Nikhil’s Web Development Helper

Nikhil Kotari has created a great little plug-in for Internet Explorer to assist primarily AJAX development. The most used features it the request logger, that logs all HTTP requests and provides you with some serializers for interpreting the responses. Deserializers included by default are Text, Hex, Image, Microsoft AJAX Partial Postbacks and JSON. The JSON and Partial postback deserializers gives you a nice little tree-view for inspecting the AJAX responses.

The newest release also features a neat JavaScript object class browser. It interprets JavaScript objects in memory and shows them in a familiar Visual Studio/C# like object browser.

IE developer toolbar

IE developer toolbar is a useful tool for DOM inspection and manipulation. My favorite feature here is that it enables me to select any element and modify the DOM and CSS properties on the fly. This gives you a quick trial-and-error approach to getting your CSS to do what you want without the need for modifying HTML and refreshing the page.

It also gives you quick access to clearing the cache, generating image reports, save out the loaded and the generated HTML, a measure tool, and a bunch of other useful tools for inspecting the page.

Fiddler Tool

Fiddler tool inspects all http request and responses from all running applications. I use this for optimizing responses by checking that gzip encoding is used and pages that should be cached is cached (inspect cache header and result code):

This tool is VERY powerful and also includes scripting, altering request/responses etc, but that is a whole other story.

Fiddler Tool works with any browser that respects Windows’ proxy settings (for instance Safari 3b doesn’t, but IE and FireFox do).

Tags:

JavaScript

The Microsoft Live Maps and Google Maps projection

by Morten 27. July 2007 05:06

I have lately seen several blogposts confused about which datum and projection Microsoft’s Live Maps (Virtual Earth) and Google Maps use. As most people already know by now, they render the round earth onto a flat screen using a Mercator projection.

I think the confusion comes from that they actually use two spatial reference systems at the same time:

  1. Geographic  Longitude/Latitude coordinatesystem based on the standard WGS84 datum.
  2. Mercator projection using a datum based on WGS84, BUT modified to be spheric.

So when is what used?

The Javascript API’s use (1) as input when you want to add points, lines and polygons. That is, they expect you to input any geometry in geographical coordinates, and click events etc. will also return geometry in this spatial reference. This is the coordinate system most javascript developers will use. The API will automatically project it to the spheric mercator projection.

If you want to create image overlays, or roll your own tile server on top of the map, you will need to project your images into a spheric mercator projection. The JavaScript APIs are not able to do this for you.

Here’s a bit of facts about the two projections:

The valid range of (1) is: [-180,-85.05112877980659] to [180, 85.05112877980659].

The valid range of (2) is: [-20037508.3427892, -20037508.3427892] to [20037508.3427892, 20037508.3427892]

Well-known Text for (1):
GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.0174532925199433]]

Well-known Text for (2):
PROJCS["Mercator Spheric", GEOGCS["WGS84basedSpheric_GCS", DATUM["WGS84basedSpheric_Datum", SPHEROID["WGS84based_Sphere", 6378137, 0], TOWGS84[0, 0, 0, 0, 0, 0, 0]], PRIMEM["Greenwich", 0, AUTHORITY["EPSG", "8901"]], UNIT["degree", 0.0174532925199433, AUTHORITY["EPSG", "9102"]], AXIS["E", EAST], AXIS["N", NORTH]], PROJECTION["Mercator"], PARAMETER["False_Easting", 0], PARAMETER["False_Northing", 0], PARAMETER["Central_Meridian", 0], PARAMETER["Latitude_of_origin", 0], UNIT["metre", 1, AUTHORITY["EPSG", "9001"]], AXIS["East", EAST], AXIS["North", NORTH]]

Proj.4 definition for (1):
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

Proj.4 definition for (2) (see here for an explanation of the weird ’nadgrids’ parameter):
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs

So why this weird extent for the latitude? First of all, the poles in the Mercator projection extends towards infinity, so at some point they have to cut them off (and who cares about ice anyway - apart from that its melting). If you look at (2) these latitude/longitude values projected into the spheric mercator results in a perfect square, fitting perfectly with squared image tiles, that are simple to sub-divide over and over again, as you zoom in. I expect the reason for the spheric datum is for simplicity and perfomance when reprojecting points from longitude/latitude to screen coordinates. Charlie Savage also has a more mathematical approach to deriving these values.

For a quick introduction to projections, coordinate systems and datums see here.

If you want to know more about how these mapping api's work, keep an eye on Jayant's blog.

Update: We now have an offical EPSG code for the projection. See details here.

Tags: ,

GIS | Google Maps | Spatial References | Virtual Earth

Profanity usage

by Morten 19. July 2007 08:04

Inspired by xkcd, here's my take on it as a javascript developer:

My Profanity Usage by Browser

To be fair to the numbers above, I first of all base my JavaScript on the Microsoft AJAX client library, so usually this works pretty well with IE7. I start out with making stuff work in IE7 and then adjust it to work in FireFox, IE6, Safari etc. This is probably why I spend more time fixing quirks in FireFox than in IE7. I'm currently doing some testing against Safari 3.0beta, and some of the issues I'm having were often resolved by making some subtle (but illogical) changes in the JavaScript, but these changes were often something I've stumbled upon by sheer luck (hence the profanities). It might just as well be because this is a beta browser. Surprisingly I do find myself spending more time working around issues and bugs in FireFox than in IE, but in the end I'm usually able to come up with a script that works in all major browsers and only have very few tweaks that tests against which browser I'm using (thank God for JS base API's that does most of that work).

IE6 wins as the browser that required the most extra code needed, just because of one thing: PNG Transparency. I need objects that need to know whether its using images that are PNG or not, so I can apply the transparency workaround (but at least this is a well-known workaround). It just complicates the JS API, requiring developers to deal with more properties to ensure it works in IE6. I can't wait till the day where we can sign of that browser version.

So why do I primarily develop in IE7, and not FireFox which seems to be the case for a lot of developers? Many reasons:

  • The debug integration with Visual Studio.NET is lightyears ahead of FireBug and all the other JS debug tools in FireFox (and is the JS console really all I get in Safari 3.0 on Windows?).
  • There are some great tools to browse and modify the DOM, see requests etc. My favorites are "Web Development Helper" which even have JSON and Microsoft AJAX Partial Postback deserializers to help you easier analyze the server responses, and IE Developer Toolbar for viewing the DOM and modifying it on the fly (priceless when you are tweaking your CSS styles).
  • It's the most used browser out there, so this is in my mind also the most important one. I'm not saying the others aren't important, but this should ensure that the most used browser also gets the most preliminary testing.
  • I know all the non-ECMA-Script properties and methods that IE adds to the DOM, so I also know which properties and methods to avoid. I'm not that familiar with Mozilla's extensions and don't want to risk using methods that doesn't exist in other browsers (that just adds to the number of profanities :-).
  • This one is probably going to give me some flaming, but I do think IE7 is the best overall browser.

 

Tags:

JavaScript | Off topic

About the author

Morten Nielsen

Silverlight MVP

Morten Nielsen
<--That's me
E-mail me Send mail

Twitter @dotMorten 

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2005-2014

Month List

Recent Comments

Comment RSS