During development of mobile app for music festivals, we had to display custom festival map overlaid over Open street map.

We used MapTiler to get Google-maps-like tiles, place them on our server and request them instead of the OSM tiles whenever map was in the festival area. However, we had to come up with solution what to display on edges of the festival map, where both custom tiles and Open street map tiles were needed. Due to nature of the tiling engine we were using, we couldn’t display two images overlaid over each other so we needed somehow to combine OSM tiles and our own into one image.

I wrote simple python script, which:

downloads OSM tiles from server

lookup custom tile in the corresponding folder ( the folder structure is based on tiles hierarchy as specified in the Tile Map Service – the same as Google maps are using )

I’ve recently rewritten a interactive visualization made for design challenge from Flash/AS3.0 to HTML/CSS/Javascript. I’ve noted few things for myself.

ActionScript vs Javascript

Sometimes rewriting something from Actionscript to Javascript is just matter of getting rid of the strong typing. Actually, I find it a good rule of thumb to write the most classes in a way you could easily rewrite them in either language. Only classes dealing with displaying visuals on one side and communicating with back-end on the other side are allowed to differ significantly due to obvious technical reasons. This helps me keeping application structure abstract. I guess it’s kinda related to the “programming TO language, not IN language” concept.

Not-messing up with DOM

At first, I hated DOM elements because they seemed to be a little smartheads that will reluctantly do what you told them to do, altough always bearing in mind their little inate quirknesses. I think it’s one the biggest mindset shifts you’re facing when moving from Flash style programming. Once you give it a thought and brushed up on some HTML knowledge, though, you can fully embrace the DOM element natural behaviour and flow in the document and end up writing actually less code. It also helps with the proper seperation concerns, if you limit the DOM access and manipulation to dedicated classes.

CSS3 Transitions

This is just great. The fact that when coding in JS, you are only concern with when things should happen, always knowing that how it will look when it happens will be specified later on in CSS. I’ve used SASS for this project, so I didn’t cared for the browser prefixes that riddle the CSS code. Cannot wait when it’s gonna be possible to specify even more in CSS, letting JS go off the visual and fancy animation stuff for its true nature.

Responsiveness

Of course, this has been a completely new aspect of the application. As usual, I’ve started with the best intentions to develop with mobiles on mind right from the beginning and make concscious effort not to forget resizing window all the time. But anyways, roughly in the middle of development, I got stuck with little problem, was happy to solve it and then just rushed towards the finish in my favorite resolution. So I had to work backwardly to accomodate for smaller resolution anyways. It was small project, so it didn’t matter that much. However, I’d like to find a way of formalizing the process of development for different resolution that would help to avoid this common pitfall.

To conclude, it was less pain to rewrite project from Flash/AS3.0 to HTML/CSS/Javacsript than I expected. As a bonus, the project got thank to its responsivness actually better than the first version. So cool.

I looked silly to me, so I tried to write a little python script, that would mimic this technique, dive into JPEG image, took some random parts of the image and cut&paste them somewhere else. The plan was to explore how tweaking with variables will change the output.

Results? All images looked terrible, even though I ended up generating over thousand images. Maybe there are some error in the script. Or perhaps this technique is just inherently flawed.

Even with Symbols introduced recently, I didn’t find a way in Google Maps Api V3 to have creative freedom while working with Markers. It was the one feature I missed most from the Flash version of the API.

So I wrote a little MapMarker class, which enables you to create Google Maps Markers from any HTML content ( including videos, iframes, vector graphics, flash files etc. ). Furthemore the HMTL within marker is is still fully accessible so you can create truly animated and fully interactive markers. The class takes advantage of the google.maps.OverlayView.

The idea for the library came to me when I was trying to replicate this flash project (http://www.geographics.cz/velov/) using gRapheal and Google Maps. It’s heavily “work in progress” and there might be some issues with performance, or certain dom elements.