Re-iterations

It's a quarter since last post? Wow, the time flies, when you're busy! :) I made a serious progress with QetriX PHP, but I spent a lot of time by "re-iterations".

In the past, when I had a little feeling something isn't right, I left it behind for when I have a time to think about it in the future and it somehow haunted me and ultimately I had to redo it, no matter how much time passed and how deeply the feature was integrated. Many times it was really painful and for this reason the core code have been rebuild from scratch a lot and I don't want to do it again any more.

So this time, whenever I have this feeling something isn't right, I start to take care of it immediately. And if it's a tough one, I start to build around it - hoping the idea will come when I see it in context.

As you might think, this really does take a lot of time. But IMO it's time well spent (and that's what I've been doing a lot since July).

Some of bigger decisions are still in front of me, like how to nicely handle QForm data or how to make (and name) opposite side of Renderer - a parser that accepts somehow encoded string (JSON, XML, picture, Word document...) and fill a component with the result.

It's a tough to find the fine line between automation and customizability. I made some quite ingenious solutions in the past, when the something adapted almost automatically with just a few lines of code, but it was a real pain, when customer needed (not wanted) it to behave or look differently.


There's no universal solution, so one of my current motos for QetriX is "just enough". If the way QetriX uses isn't suitable for you, write your own Renderer, or please use something else. It may sound harsh, but it's a way out of the feature loop, which leads to overblown code.

GeoQetriX Map

I presented the idea of GeoQetriX more than a year ago, but finally I got the urge to make it done. I'm gonna to redo my website about "USA thru Czech Eyes", so I wanted some interactive maps. I found some JavaScript libraries, based on Raphaël, and using SVG paths for countries.

So I downloaded some countries. And some more countries. And this country, this one, and... but at least one of them was missing. So, as one might expect, it brought me to an idea to do it on my own (to have them all). I'm gonna to need them anyway at some point, so why not now?

Because Google Maps JavaScript API is truly extraordinary, I didn't think twice how I'm going to do the editor.

So. I put some geographical points (using markers) on the map and stored them in the database. It were basically major country border joints and major shore features. In the very first version, the editor generated SQL code, which I executed manually in HeidiSQL.

Then, of course, I had to stop being lazy about DB support and created a script to generate JSON for markers on the map, later for lines as well. Markers and lines both have a type, with semantic meaning (shore border, inland border, division border...).

Except for the Google Maps I created a secondary output, into generated PNG. For debug purposes I assigned different colors to each type (blue for shore, red for inland, green for divisions, gray for subdivisions). And started clicking. And clicking... But after a while I was quite excited about the (still work-in-progress) result:

World Map

Along the way, I adjusted something here and there. The editor has to be very easy to use, because I guess I'm gonna spend quite a time in it. I want to have major roads and railroads, along with water.

I also had to use a projection for the map output. I chose Miller (EPSG:54003 - World Miller Cylindrical), because personally I like it the most; for me it's a "classic" view.

1:1 cut of Europe

Before the final alpha-stage map I did everything I planned to. Like placemark settings with a list of attached lines, with possibility to change type of the line, delete selected line or add a midpoint to a line.

1:1 cut of USA

The last thing is to define, what's on each side of a line. At first I thought it will be the smallest unit possible (like a county, neighborhood or even a plot), but I kept thinking that querying the whole country may consist of thousands of geo-units.

After a while I realized, that the other way around it would be much better, without losing much fidelity. So at this point I'll define a country (or sea/ocean) for each line, if it's a country border. Then state borders, county borders and so on. If I would like to draw a country, I simply ask for all lines with it's ID.

Clickable SVG map

I created QetriX Map with SVG in mind. But I wasn't pleased about how to make it clickable. It requires Raphaël JS library and it's not as friendly as I would like.

Wrong.

There's something called "XLink", which allows creating hyperlinks within XML documents (therefore in SVG as well).

In HTML you can use <a xlink:href="http://example.com"><path d="..."></a>. And it works simply like that. Any SVG element works as a link - circle, line, polyline, path and more.

In plain SVG you have to also add a proper xlink namespace xmlns:xlink="http://www.w3.org/1999/xlink" in SVG tag, otherwise you'll get an error message: "XML Parsing Error: prefix not bound to a namespace".

HTML example:
<!DOCTYPE html>
<html>
<body>
<svg version="1.0" width="100" height="100">
    <a xlink:href="#ad"><circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow" /></a>
</svg>
</body>
</html>

SVG example:
<svg version="1.0" id="svg" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100" height="100">    <a xlink:href="#c1"><circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow" /></a>
</svg>

Anyway, not everything is bright and shiny, working CSS doesn't mean, it will behave the same, as in HTML. SVG has it's own attributes (background become fill, border become stroke) and doesn't support those I got used to work with in HTML - like z-index. I'd like to highlight a path by changing stroke color and width, but only part of it is visible. It's because z-index in SVG is fixed by position of the element in XML, so part of the outline is overlapped by nearby element defined further in the XML. The only way is DOM reordering, which is quite expensive (resources-wide).

June and July 2014

As usual, I had quite a lot of stuff going on. First of all, I was working on PHP framework for QetriX. I got it working (and I'm quite satisfied with it), but it would take a lot of effort to make it done completely.

Then I learned to use location in Objective-C, especially in background. When I was about to finish, Apple announced Swift, so I created a few small apps in it, but unfortunately from the beta Xcode it's not allowed to publish them to the Store yet.

One of the apps was a database of address points in the Czech Republic. Because I needed various kinds of data, I "accidentaly" found a new source of such data for QetriX. I started just with EU (NUTS and LAU areas), but expanded to the US as well. Instead of importing from TSV right into QetriX, this time I imported it from source CSV to custom table. I hope I would be able to see the data better (because of SQL JOINs and such).

For the mobile app of CZ Address Points I created a QetriX based website. Because it involved some CSS, I also updated reference pages for grid and "friendly" colors - consisting only from pairs of 0, 3, 6, 9, C and F hex numbers.

QetriX Friendly Colors

QetriX Grid

Because I had to prepare DB and manage Types, I also made progress in QetriX Apmin, analogy to Adminer - single PHP file for complete management (of QetriX apps).