I’ve been working (in my decreasing available spare time) on a project to pull together into a project called “Pipe Cleaner” all the various concepts I’ve been mentioning on this blog: Web Object Records (WORK) for API Access and object manipulation, Djolt for generating text from templates, Data/Query/Transform/Template (DQT) for transforming data and JD for scripting these elements together. The pieces came together this morning enough to put a demo together and here it is – the Toronto Fires Pt II Demo.
How, you may ask, does this differ from the original Toronto Fires Demo? The answer is how it is put together, which we describe here.
Index.dj
This is the Djolt template that generates the output. The data fed to this template is generate by the JD script, described in the next section.
<html>
<head>
<link rel="stylesheet" type="text/css" href="css.css" />
{{ gmaps.js|safe }}
</head>
<body>
<div id="content_wrapper">
<div id="map_wrapper">
{{ gmaps.html|safe }}
</div>
<div id="text_wrapper">
{% for incident in incidents %}
<div id="{{ incident.IncidentNumber }}">
{{ incident.body_sb|safe }}
</div>
{% endfor %}
</div>
</body>
</html>
Quite simple … as you can see, most of the data is being pulled in from elsewhere. The elsewhere is provided by the script described in the next section.
Index.jd
This is the script that pull all the pieces together. Note that I’m not 100% happy with the way the data is imported, I would like the geocoding to become part of this data flow too. In the next release perhaps.
First we pull in the “fire” module that we wrote in the previous Map examples. This is doing exactly what you think: importing a Python module. We may have to increase the security or restrict this to working with an API for general purpose use.
import module:"fire";
Next we define two headers – one that is going to appear in the Google Maps popup, the next that is going to appear in the sidebar. They need to be different as they refer to themselves. Note that the sidebar header “breaks” the encapsulation of Google Maps – this seems to be unavoidable. The to:"fitem.head.map" and to:"fitem.head.sb" are manipulating a WORK dictionary to store values.
Note also here that we’ve extended JD to accept Python multiline strings – this was unavoidable if JD was to be useful to me.
set to:"fitem.head.map" value:"""
<h3>
<a href="#{{ IncidentNumber }}">{{ AlarmLevel}}: {{ IncidentType }} on {{ RawStreet }}
</h3>
""";
set to:"fitem.head.sb" value:"""
<h3>
{% if latitude and longitude %}
<a href="javascript:js_maps.map.panTo(new GLatLng({{ latitude }}, {{ longitude }}))">*
{% endif %}
<a href="#{{ IncidentNumber }}">{{ AlarmLevel}}: {{ IncidentType }} on {{ RawStreet }}
</h3>
""";
The next block defines the text of the body used to describe a fire incident. It follows much the same pattern as the previous block.
set to:"fitem.body" value:"""
<p>
Alarm Level: {{ AlarmLevel }}
<br />
Incident Type: {{ IncidentType }}
<br />
City: {{ City }}
<br />
Street: {{ Street }} ({{ CrossStreet }})
<br />
Units: {{ Units }}
</p>
""";
This is a map: it is translating the values in fire.GetGeocodeIncidents into a new format and storing that in incidents. The format that we were are storing it in is understood by the Google Maps generating module.
We may rename this translate, as the word map is somewhat overloaded.
map from:"fire.GetGeocodedIncidents" to:"incidents" map:{
"latitude" : "{{ latitude }}",
"longitude" : "{{ longitude }}",
"title" : "{{ AlarmLevel}}: {{ IncidentType }} on {{ RawStreet }}",
"uri" : "{{ HOME_URI }}#{{ IncidentNumber }}",
"body" : "{{ *fitem.head.map|safe }}{{ *fitem.body|safe }}",
"body_sb" : "{{ *fitem.head.sb|safe }}{{ *fitem.body|safe }}",
"IncidentNumber" : "{{ IncidentNumber }}"
};
Next we set up the “meta” (see WORK meta description if you’re not following along) for the maps. The render_value:true declaration makes PC interpret the templates in strings). We then call our Google Maps generating code (which are actually more Pipe Cleaners) and that gets fed to the Djolt template we first showed you. Clear? Maybe not, we’ll have more examples coming…
set to:"map_meta" render_value:true value:{
"id" : "maps",
"latitude" : 43.67,
"longitude" : -79.38,
"uzoom" : -13,
"gzoom" : 13,
"api_key" : "{{ cfg.gmaps.api_key|otherwise:'...mykey...' }}",
"html" : {
"width" : "1024px",
"height" : "800px"
}
};
load template:"gmaps.js" items:"incidents" meta:"map_meta";
load template:"gmaps.html" items:"incidents" meta:"map_meta";
The Google Maps API is the great granddaddy of mapping API. Originally, the GMap API was an internal private Google API until 
Next up in our tour of Javascript mapping APIs is 
This post should be subtitled “
Yahoo is a nice alternative service to Google Maps for displaying maps on your website or service. Amongst its benefits: