Zaemis' Digital Junk Drawer

Tradukita de la angla, kiun oni povas trovi ĉe zaemis.blogspot.com/2011/01/geolocation-search.html. Koran dankon al mia amiko, Benĉjo S, pro lia kontrol-helpo.

La populareco de servoj, kiuj permesas identigi proksimajn lokojn de intereso, daŭre kreskas pli. Mi certas, ke ĉiuj konas sociajn retejojn, kiuj permesas serĉi profilojn de homoj per poŝtkodo, aŭ mobilajn programojn, kiuj uzas geo-lokilon por identigi tajajn restoraciojn en la promenebla distanco. Surprize, oni simple aplikas tian funkciecon, kaj, en ĉi artiklo, mi diskutos, kiel fari tion.

La unua ŝtupo estas akiri la latitudan kaj longitudan koordinatojn de ajna loko, kiun vi serĉigeblos. Por la restoracia scenaro, akiru la latitudon kaj longitudon de ĉiu manĝejo. Por la soci-reteja scenaro, listigu poŝtkodojn kun la latitudoj kaj longitudoj de ĉies mezpunktoj.

Ĝenerale, poŝtkoda serĉilo estas malbona ideo; ĉies limoj malofte igas simplan plurlateron, la areoj malsamas per grandeco, kaj ĉiu povas ŝanĝiĝi laŭ la volo de la poŝtservo. Sed ofte, ni estas ligataj per la kondiĉoj de niaj klientoj, kiuj volas aĵojn, kiujn ni konas pli bone ol fari. Tial mi tenas miajn opiniaĉojn for de vi, kaj anstataŭe petas, ke vi memoras jene:

• ZCTA ne estas poŝtkodoj, do ne uzu ilin tielmaniere. Iuj rekomendas uzi la ZCTA datumon de la Usana Kontado Ministerio por la jaro 2000 kiel senkostan poŝtkodan kaj latitudan kaj longitudan datumon en Usono, sed la ministeria retejo avertas, ke ZCTA estis kreita por signi lokojn de kontado. Ili ne ĉiam kongruas kun la lokoj, kiuj estas signataj de la usona poŝtservo. Nepopulataj lokoj, kiel lagoj kaj arbaroj, povas havi proprajn ZCTA kodojn, kaj eblas ke pli etaj poŝtkodoj “ne aperi en la ZCTA mondo.”
  
  
• Poŝtkodoj estas malstabilaj, do estu certe, ke vi komprenas la regularon pri ĝisdatigo de via datum-firmao. CD Light, LLC vendas datumarojn, kiun ili licencigas de Usona Poŝta Servo kaj Canada Post, kaj poste ili plibonigas kaj subtenas la datumon per pluraj pliaj fontoj. Ili aldonas novajn poŝtkodojn kaj forigas malaktualajn kodojn de siaj datumaroj. Trimonataj kaj monataj ĝisdatigoj estas haveblaj per bonprezigita abono. Aliflanke, federalgovernmentzipcodes.us havas senkostan usonan poŝtkodan datumaron, kiu estas malregular-ĝisdataga per malgranda aro de fontoj. Malaktualaj poŝtkodoj estas inkludataj, sed estas signataj “malkomisiita.” Tamen, ne estas klare, kiu firmao aŭ persono produktas tiun.

Ĉu vi mem gastigas vian datumaron, ĉu vi uzas ret-servon kiel GeoCoder.ca, memsciigado pri la penoj, kiuj farendas por konstrui ĝin el nuna datumaro kaj por subteni la precizecon, ne estas malbona ideo. Estas pli bone havi pli-specifajn/precizajn datumojn ol malpli.

La dua ŝtupo estas evoluigi taŭgan strategion por serĉi tra viaj datumoj. Vi ne volas kalkuli la distancon de konata fonto al ĉiuj celaj koordinatoj; la naiva kaj kruda serĉado estas malofte dezirata, eĉ se la datumaro estas malgranda kaj la trafiko al via programo/retejo estas malalta. Mia procezo estas kalkuli la latitudojn kaj longitudojn de la norda, okcidenta, suda, kaj orienta limoj de la serĉo (direktoj de 0°, 90°, 180°, kaj -90° aŭ 270° respektive). Tiam, mi serĉas tra la subaro de rekordoj, kiuj havas restantajn lokojn en ĉi tiu limigujo.

Mi uzas la jenajn formulojn por kalkuli la celajn nombrojn, kaj limigi mian datum-serĉon:

Vidu:

• d estas distanco
• R estas la radiuso de la Tero (la duon-granda akso estas 3,963.19 mejloj laŭ la WGS84 modelo)
• ᵩ estas latitudo
• λ is longitudo
• θ estas direkto

Kodigitaj, la formuloj aspektas jene:

// kalkuli lat/lon-n de destino per donita komencaj loko, direkto, kaj distanco
function destino($lat,$lon, $direkto, $distanco,$mezuro="mi") {
    $radiuso = strcasecmp($mezuro, "km") ? 3963.19 : 6378.137;
    $rLat = deg2rad($lat);
    $rLon = deg2rad($lon);
    $rDirekto = deg2rad($direkto);
    $rAngDist = $distanco / $radiuso;
    $rLatB = asin(sin($rLat) * cos($rAngDist) +
        cos($rLat) * sin($rAngDist) * cos($rDirekto));
    $rLonB = $rLon + atan2(sin($rDirekto) * sin($rAngDist) * cos($rLat),
        cos($rAngDist) - sin($rLat) * sin($rLatB));
    return array("lat" => rad2deg($rLatB), "lon" => rad2deg($rLonB));
}

Simpla ĉirkauflua-funkcio vokus tiun ree kun malsamaj direktoj kaj atingi la serĉ-limojn:

// kalkuli limigujon
function limigoj($lat,$lon, $distanco,$mezuro="mi") {
    return array(
        "No" => destino($lat,$lon,   0, $distanco,$mezuro),
        "Or" => destino($lat,$lon,  90, $distanco,$mezuro),
        "Su" => destino($lat,$lon, 180, $distanco,$mezuro),
        "Ok" => destino($lat,$lon, 270, $distanco,$mezuro));
}

Rekordoj, kiuj estas trovataj inter la serĉ-loko, ankoraŭ bezonas esti limigataj, kaj mi uzas ĉi tiun formulon por kalkuli la disteancon inter du koordinatoj:

Kode, la formulo aspektas jene:

// kalkuli distancon inter du lat/lon koordinatoj
function distanco($latA,$lonA, $latB,$lonB, $mezuro="mi") {
    $radiuso = strcasecmp($mezuro, "km") ? 3963.19 : 6378.137;
    $rLatA = deg2rad($latA);
    $rLatB = deg2rad($latB);
    $rDuonSxangxLat = deg2rad(($latB - $latA) / 2);
    $rDuonSxangxLon = deg2rad(($lonB - $lonA) / 2);
    return 2 * $radiuso * asin(sqrt(pow(sin($rDuonSxangxLat), 2) +
         cos($rLatA) * cos($rLatB) * pow(sin($rDuonSxangxLon), 2)));
}

Serĉado per tiuj funkcioj aspektus jene ($latitudo kaj $longitudo estas la font-koordinatojn, kaj $distanco kaj $mezuro signas la deziratan serĉ-radiuson):

$lim = limigoj($latitudo,$longitudo, $distanco,$mezuro);
$peto = "SELECT loka_nomo, adreso, urbo, sxtato, posxtkodo,
    latitudo, longitudo FROM lokoj WHERE
    latitudo BETWEEN {$lim["Su"]["lat"]} AND {$lim["No"]["lat"]} AND
    longitudo BETWEEN {$lim["Ok"]["lon"]} AND {$lim["Or"]["lon"]}";
$rezulto = $db->query($peto);
$lokoj = array();
while ($vico = $rezulto->fetch(PDO::FETCH_ASSOC)) {
    $dist = distanco($latitudo,$longitudo, $vico["latitudo"],$vico["longitudo"], $mezuro);
    if ($dist <= $distanco) {
        $lokoj[] = array(
            "nomo"      => $vico["loka_nomo"],
            "adreso"    => $vico["adreso"],
            "urbo"      => $vico["urbo"],
            "sxtato"    => $vico["sxtato"],
            "posxtkodo" => $vico["posxtkodo"],
            "distanco"  => round($dist, 2));
    }
}

Havi profundan komprenadon de navigadaj matematikoj estas bona, sed tio ne estas necesa. Bonŝance, ni vivas dum tempo kiam oni povas trovi taŭgajn formulojn per facila ret-serĉo, kaj diskutoj, temataj pri la bonoj kaj malbonoj inter la simplecoj kaj precizecoj de la formuloj, estas facile troveble. Mi uzas formulojn, kiu estas bazitaj sur la formulo de Haversin. Ilia precizo sufiĉas por miaj bezonoj. Aliaj formuloj, kiel Vincenty’s Formulae, sinkoncernas pri la elipsa eco de la Tero kaj produktas pli-precizajn rezultojn, sed mi helpas personoj trovi proksimajn amikojn aŭ firmaojn… ne programas krozmisilojn.

La fina ŝtupo estas akiri la font-koordinatojn. Por la poŝtkoda ekzemplo ĉe la komenco, oni trovas la mezpunktan latitudon kaj longitudon de la poŝtkodo kaj uzi ĝin tiel serĉ-fonto. Se viaj celaj uzantaroj estas akceptemaj, vi konsiderus utiligi la geo-lokan API de JavaScript, difinita de la W3C. La API montras la objekton navigator.geolocation, kiu povas akiri la aktualan lokon de la uzanto. La uzanto malofte konas siajn precizajn koordinatojn, sed multe ret-kapablaĵoj kaj “inteligentaj telefonoj” nun havas GPS-kapablecon, kiun la retfoliumilo povas uzi. navigator.geolocation.getCurrentPosition() igis la foliumilon peti por permiso de la uzanto por montri la lokon, kaj se uzanto donas sian permison, ĝi vokas re-vokitan funkcion.

<form>
 Search <input id="tksDist" maxlength="3" name="distanco" size="3" type="text">
 <select name="mezuro">
  <option value="mi">mi</option>
  <option value="km">km</option>
 </select> de<br>
 <input checked="checked" name="sercxPer" type="radio"
  value="posxtkodo">poŝtkodo
 <input maxlength="5" name="posxtkodo" size="5" type="text"><br>
 <input id="koordj" name="sercxPer" type="radio"
  value="koordj">koordinatoj
 <input id="tksLat" maxlength="10" name="latitudo" size="6"
  type="text"> Lat.
 <input id="tksLon" maxlength="10" name="longitudo" size="6"
  type="text"> Lon.<br>
 <input type="submit" value="Serĉi">
<form>
<script type="text/javascript">
(function () {
    function metKoordj(poz) {
        document.getElementById("koordj").checked = true;
        document.getElementById("tksLat").value =
            pos.coordinates.latitude;
        document.getElementById("tksLon").value =
            pos.coordinates.longitude;
    }

    if (navigator.geolocation) {
        navigator.geolocation.getCurrentPosition(metKoordj);
    }
})();
</script>


Espere, vi nun povas vidi, kiel facile estas aldoni serĉadon por interesaj proksimaj lokoj al via ret-programo. Unue kaj plejantaŭe, estas grave subteni sanan datumaron, ĉar, eĉ se uzantoj komprenas ke la rezultoj estas malprecizaj, vi neniam povas sendi bonajn rezultojn per malbona datumaro. Estas plejparte simple dungi necesajn algoritmojn por efike serĉi tra la aro, kaj mi montris al vi tiun, kiun mi uzas; aliaj algoritmoj kaj formuloj estas troveblaj kaj uzeblaj se vi bezonas pli precizajn rezultojn. Kaj modernaj API-j, kiel navigator.geolocation, ebligas al vi proponi novajn manierojn, kiujn la uzantoj povas utiligi vian datumaron. Bonvolu aldiri viajn pensojn kaj spertojn al la komentoj sube.

Tradukita de la angla, kiun oni povas trovi ĉe zaemis.blogspot.com/2011/10/please-god-give-me-something-new.html. Koran dankon al mia amiko, Jon Z, kaj 黄鸡蛋/Ĉitano pro ilia kontrol-helpo.

“Jen…rigardu ĉi tiun <ligilon>. Sed, vi devas uzi la plej freŝan version de Chrome.” Aĉ! Ĉu ni ne jam spertis tion? 15 jaroj pasis, kaj ni nun reiras rekte al la sama loko, kie ni ekiris… “Plej bone aspekta pere de <ies plej ŝatatan retfoliumilon>.” Estas domaĝe.

Ne min miskomprenu. Jaroj da laboro por normigi HTML, JavaScript, la DOM, CSS, ktp klarigis multajn malklaraĵojn, kaj tio ja estis necesa. Sed striktaj reguloj ankaŭ sufokas kreadon. Ĉar HTML5 kaj ĝiaj amikoj forigis kelkajn el la limigoj, la pendolo svingiĝi antaŭen. Homoj ekkreas denove. Sed, nun kontraŭas Firefox kaj Chrome anstataŭ Internet Explorer kaj Netscape.

Tamen, estas sistema problemo preter la “foliumiloj militoj.” Ĉu vi memoras AOL? Facebook nun klopodas esti “La Interreto.” Ĉu vi memoras komputilegojn kaj verd-ekrajnojn? Ni puŝis ĉion al la komputila labortablo, kaj nun puŝas ĉion reen “al La Nubo.” Ĉiuj el la kvara kaj kvina generaciaj programlingvoj venis kaj foriris, kaj la plej bonaj, kiujn ni nun havas, estas Java kaj Clojure?! Ĉu vi memoras Ajax, nu mi volas diri DHTML, nu mi volas diri JavaScript? Ĉiuj “novigas,” sed neniu vere faras ion novan, ekscitan, aŭ unikan.

Damne, Tesla ŝtopis 200 lumampolojn teren, kaj lumigis ilin 25-mejloj for de elektra fonto en 1899, kaj Solyndra kaj Prius ankoraŭ estas la plej bonaj? Kio okazas?!

La sinusa ciklo de teknologiaj avancoj ne estus malbona, se ĉiu ciklo donus ion novan. Eble tial mi enuiĝis: ĉiu ciklo ŝajne refaradas la antaŭan ciklon, kaj neniam estas io vere nova kaj ekscita. Ni moviĝas ronde, ne spirale. Ju pli io ŝanĝiĝas, des pli ĉio restas sama. Ĉu Quindlen estas ĝusta, ke ĉiuj rakonto jam estis dirita?

Pensu pri la canvas elemento de HTML5, kiun ĉiuj laŭdas kaj opinias tiel bonega kaj mirinda, 2-dimensia desegno, kiun oni povas influi per JavaScript. Se foliumiloj farigus bonan subtenon por SVG antaŭ 10 jaroj, ni ne nun bezonus canvas. Fakte, ni jam havas tiun “novan, ekcitan teknologion” de 10 jaroj. Bedaŭrinde, SVG estas plibonega mult-maniere. Bedaŭrinde, ni havis 3-dimensian kapablecon per VRM/X3D ekde la 1990-aj jaroj. Bedaŭrine, ni kontentigis nin mem per io, kio estas malpli bona, kaj ni ridetas de orelo al orelo.

Ĉu vi ne ŝatus havi la teknologion de la estonteco 10 jarojn de nun? Tente. Sed mi ne certas ĉu mi deziros tiun… ĉar verŝajne, ĝi estos la sama kiel tio, kion mi jam havas nun dum la pasintaj 10-jaroj. Ĝi nur havas novan kampanjon de merkatiko.

When conditionally initializing several variables, what’s a better approach? This…

<?php
$a = "";
$b = 42;
if ($someCondition) {
    $a = "hello";
    $b = 7;
}

or this…

<?php
if ($someCondition) {
    $a = "hello";
    $b = 7;
}
else {
    $a = "";
    $b = 42;
}

The first does extra work by potentially setting the variables twice, but is less lines of code and may be more comfortable to those not used to PHP’s loosey-goosey scoping. The second avoids the extra work and demonstrates an understanding of PHP scope.

I don’t have a concrete answer.

Multaj pasvortoj estis ŝtelitaj de LinkedIn kaj aliaj retejoj; tiu igis min pripensante: se mi ŝanĝus miajn pasvortojn, uzante esperantajn literojn, ĉu ili estus pli sekuraj?

Ĝi necesigas Esperantan klavaron. Mi havas tiun kaj hejme kaj laboreje, sed mi ne povus uzi retejojn per aliaj komputiloj.

Ĉu tiu estas malbona ideo, aŭ ĉu ne?

Mi ne sentis sane kaj mi dormis multe hodaŭ, tial mi ne faris multe.

Mi redaktis kelkajn artikolojn por phpmaster.com, kaj babilis kun amikoj per ret-mesaĝilo (ni grumblis pri altaj impostoj).

Morgaŭ, mi vizitos la dentiston… Hodiaŭ estis malekcita tago. Morgaŭ estos malgoja tago!

Antaŭ unu aŭ du monatoj, mi aĉetis la libron “Vivo de Zamenhof” de Privat. Ĝi estas laŭdita en Esperantujo. Tamen, mi ne  ĝuas la libron, kaj mi malfacilege finlegos ĝin.

Mi ne ŝatas biografiojn. Mi ne zorgas, kiel oni iris de tie al ĉi tie, aŭ, kion oni diris. Tio enuigas min!

Mi pli preferas aŭbiografiojn. Mi ŝatas, kiam oni rakonas per memvortoj. Mi ŝatas vidi personecojn! Certe tiu estas malpli enua ol la alia!

Hodiaŭ, mi devas skribi ion ĉar la esperanta defio. Sed  nenio interesa okazis! Mi nur laboris, dormetis, kaj ludis Kolerajn Birdojn (“Angry Birds”).

Mi gajnis la restajn nivelojn de la unua ludo, kaj nun tiu, “Rio”, kaj “Spaco” estis gajnitaj tute. Kelkaj niveloj tro frustigis min!

Nun mi ludos “Sezonoj”.

Por plibonigi mian Esperanton, mi decidas skribi iom da Esperanto ĉiutage dum kvin tagoj.

Ĉiu rakonto ne devas esti longa; nur gravas, ke mi skribas ion ĉiutage. Kaj se mi ne havus interesan rakonton pri mia vivo, eble mi tradukus ion. Mi metos la skribaĵojn surrete, tial iu ajn povas korekti miajn erarojn per komentojn (certe, mi eraros!)

Do, saluton kaj bonvenon… konŝancigu min!

So I upgraded to 12.04 LTS, Precise Pangolin. Not only do I not know what a Pangolin is, it deleted MySQL.

tboronczyk@laptop:~/$ mysql -u dbuser mydatabase
The program ‘mysql’ is currently not installed. You can install it by typing:
sudo apt-get install mysql-client-core-5.5
tboronczyk@laptop:~/$ history | grep mysql
1152 mysql
1153 mysql -u dbuser mydatabase
1156 mysql -u dbuser mydatabase < schema.sql
1212 mysql -u dbuser mydatabase
1331 mysql -u dbuser mydatabase < data1.sql
1332 mysql -u dbuser mydatabase < data2.sql
1366 mysql -u root
2025 mysql -u dbuser mydatabase
2026 history | grep mysql

As the history command shows, it used to be there. Great job, Ubuntu!